Hacker News Reader

This middle ground is also why I think Go would be/is a great learning language at colleges or in general.

You've got something which has a lot in similar with dynamic languages, doesn't require much to learn Hello World (in comparison to Java), but has higher-level features like GC, first-class functions, etc. You also learn something C-ish in pointers which you might be aware of but not truly know in dynamic langs. Concurrency is only a benefit.

It is a really simple language that anyone can learn quickly and then take that knowledge higher level with a Python or even Clojure or Haskell or lower level with a C.

Is anyone aware of Go being used as a teaching tool in an academic environment?

For a scripting language, Go is very strict with compile-time errors that could just as well be warnings. Unused variables, unused imports, dead code, etc. Other than that, I could see Go as a pretty useful scripting and systems language.

In case anyone else is wondering why doesn't the Go compiler have error ignore flags for scripting/prototyping purposes:

http://weekly.golang.org/doc/faq#unused_variables_and_import...

Using the term "scripting language" for either Go or Python is a complete misnomer.

Back in the day, languages called as such where so slow, that there was a feeling that they were used "in lieu" of "real" programming languages. They were there to extend "real" software.

Today? Much the opposite. Computing power is almost always cheaper than brain power, and we use C to extend Python rather than the other way around.

For that matter, I think Go is great for networked infrastructure, but bad for interfacing with other languages and still significantly harder to learn than Python, Julia and R.

That is why I caution on the use of Go in projects which have "scientific" bent to them...

Go is way easier to learn than Python for real applications. Python might be easier for your first few times playing with a programming language, but the complexity ramps up fast. There are a lot of features in python - classes, decorators, all the __foo__ stuff... I think it's a lot easier to understand all of Go than all of Python.

I can't comment on R or Julia, since I haven't used them, but I would doubt they're simpler than Go.

I understand pushing back against the idea that Go is a scripting language.

Arguing that Python isn't a "scripting language" is a complete waste of time. That ship sailed at least 5 years ago, if not 15.

And Python is still very, very slow, and very difficult to make multicore (if you disagree, compare with Go), and there are plenty of domains where it should not be chosen as a result. Yes, I know about PyPy, but that project's performance characteristics are very strange and certainly isn't "it just speeds up Python code by 10x, all the time"... sometimes it does that, sometimes (rarely) it slows it down, mostly it does something in the middle that certainly doesn't bring Python anywhere near C.

For me, a scripting language is used to extend a larger more inflexible software project. Like scripting in Office Suites, Blender or similar.

Python is growing in popularity, and in the majority of cases it is used as the "primary" language now. That's why "scripting" is a misnomer, even if technically CPython is not compiled to machine language.

All of what you said about performance could just as easily be said for modern implementations of Common Lisps. SBCL, for example, fairs quite well against Go despite being much more dynamic than either Python or Ruby: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

Not as well when we use more than one core:

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

I wonder if that would still be the case against commercial Lisp compilers like Allegro Common Lisp.

Another view is that things like GC sacrifice low-level performance stuff (you reference not having total system-level control) while the similarity to languages like C sacrifices some of the good characteristics of scripting languages.

This development/trend seems to show that the value of the "dynamicity" of scripting languages have perhaps been overrated. There seems to be a set of abstractions with reasonably/very good mechanical sympathy that are both easy to understand and use, and that doesn't constrain you that much with regards to factorability and coding iteration.

If there was a time when dynamic typing was overrated, then it is certainly possible that this time is a time when static typing is overrated.

"If there was a time when dynamic typing was overrated, then it is certainly possible that this time is a time when static typing is overrated."

I think that's actually a very important aspect of understanding where dynamic typing as a hugely popular thing came from. Today, I favor static typing. However, given a choice of Python or 1990s-C++, I'll take Python. It could be argued that the static typing world needed to be dethroned and be forced to improve itself in the face of the dynamic competition to become what it is today.

On the other hand, pretending that "static typing" is the same today as it was 20 years ago is merely the complementary failure that people too bedazzled by static typing 20 years ago and dismissed the oncoming dynamic typing wave made.

:)

Another kind of typing system is a mixture of dynamic and static typing named: gradual typing (PHP/Hack, JS, ActionScript, etc.) http://en.wikipedia.org/wiki/Gradual_typing

There is also the difference between strong and weak typing: http://en.wikipedia.org/wiki/Strong_and_weak_typing

It's certainly possible that there was a time when virtual machine based language implementations where overrated.

I didn't really mean dynamic typing (that's why I wrote "dynamicity" with question mark).

To be clearer: the ability for things to change at runtime, i.e. for the programmer to do things like monkey patching. I guess dynamic typing is related to this, at least in the sense that you'll have to give up on some static typing in order to get more flexible dynamic behaviour.

And yeah, I realize that Python et. al. is used for real apps, and certainly not just for scripting tasks.

The real value of dynamic languages can only be realized in dynamic, image-based, live programming environments like the kind you have with Lisp and Smalltalk.

Whether "scripting" languages, as in languages used to write small, one-off programs, or programs to automate systems administration tasks or to glue other programs together, benefit from that type of power is debatable, but Ruby, Python, and Perl have never been particularly good representatives of the dynamic language paradigm as a whole, either conceptually or implementation-wise.

> like the kind you have with Lisp and Smalltalk

...and PHP and JavaScript

There's a reason that I wrote 'scripting languages' instead of dynamic languages. Python, Ruby etc. seem to be more regarded as scripting languages than Lisp and Smalltalk.

For me it seems to be hitting that niche of "one off" programs that have a nack for sticking around forever. Once I figure out something needs to become software and not be truly one off, then I find myself reaching for Go.