"It doesn't check any of the scripting language boxes I've ever heard of."

Well, as I sort of implied but will now spell out, the 1990s produced a certain stereotypical definition of a "scripting language" that I think is ultimately overspecified. A 1990s scripting language is extremely dynamic, including the type system, everything's boxed, everything's a hash table of one form or another, and in general everything converges to produce a language that is very fluid, but ultimately very slow. These were overreactions to the languages of the day, which were, I think, easy to forget how hard they were to use in practice. Even when you use C or C++ today, you're still using it with radically better community best practices, libraries, and better tool support. 1990s C++ was some hard stuff to work with even before you let threading in. Into that world, Perl and Python were a breath of fresh air!

It is easy to get deceived by the constant stream of benchmarks that are 50% faster than last month and the constant stream of incredibly-micro micro-benchmarks where JS or something is as fast as C at adding together small integers in an array or something. The reality is that after years and years and years of work, they're fundamentally slow. Yes, even Javascript; remember, for asm.js to produce such fantastic speedups, Javascript must be leaving that much performance on the table.

Go ends up in practice working very like a scripting language; line counts are virtually identical in my experience, logic is very similar, and the fluidity is there, partially by virtue of ignoring the very things that Rust brings out and makes explicit (the ownership and such). I can't say with a straight face that the logic comes out the same, the way a Perl program can be virtually transliterated into Python, because the ability to use concurrency seriously means that you don't have to bend into the contortions you sometimes do to simulate it in those older languages, but otherwise it works similarly, except that you use structs and interfaces instead.

Scripting 1.0, being made when this world was younger and 150MHz was a fast machine, made some mistakes in thinking that compilers would eventually be able to overcome their fundamental weaknesses. It was a neat experiment to make everything wildly dynamic, but in the end, you end up paying and paying and paying and paying and paying for that dynamism, but you only use it rarely. You may be inclined to object, saying "I use it all the time! I use Ruby gems to assemble all sorts of complicated and interesting objects!", but that's because we humans are really bad at order of magnitudes inside of programs... you set up your objects essentially once at the "beginning" of some computation, then you pay for that dynamism billions of times. You pay for the awesome exception handling all the time, yet only use it rarely. You pay... etc.

Scripting 1.0 also accidentally interpreted the failures of the languages of the day, which were all statically typed, as being significantly caused by static typing. I'd suggest we've since learned that the static typing of the time was simply bad; the languages are not all that great, and the ways they were used even worse (inheritance favored over composition, etc.). So they whiplashed wildly to the opposite, which turns out to have been an overreaction similar to the previous paragraphs. You pay for all that typing dynamism all the time, yet in practice, legal inputs to a given function are characterized by a limited number of types, legal outputs also, and all this dynamism is really going to waste. (Go's interfaces capture %95 of the use cases here while still being perfectly statically typed. There are other possibilities as well for other languages to explore.)

Scripting 2.0 is fixing that problem by creating languages that judiciously use dynamism instead of indiscriminately slathering it everywhere, that are merely somewhat slower than C rather than the night-and-day of 1.0, are still fairly easy to program in even if they are not as wildly dynamic, and execute an order of magnitude faster than Python or Perl or JS while also obtaining the advantages of more static typing for software quality. Go is merely the most prominent of this line of language, there's a whole bunch of them bubbling up right now. Julia is trying to fit into this for numeric computing, LuaJIT is sitting there sipping the punch wondering why all the other languages are so many years late to the party, there's another language that's popped up on HN every so often in the past few months that fits in here but escapes my mind, and I think we're going to see more of this. With computer processors speeds having stalled it becomes a difficult proposition to go up to a programmer and promise them the moon, and all they have to do is be willing to be 20-100x slower than the competition, and, uh, well, no, you won't just catch up in 5 years of processor advancement because raw clock speeds are stalled.

So I find in practice Go is a Scripting 2.0 language. You write it at roughly Python speeds, it runs much faster and works much better in the cloud where that actually matters, and part of the way it accomplishes this is to do things like gloss over memory management details and exactly how interfaces are satisfied (dynamic lookup at runtime, compare with wycat's comments in the thread on how Rust does it), and generally focuses on being relatively easy and fast to write. Looking at it from another direction, compare Go to Rust and Go looks more like a scripting language than a competitor to Rust.

I could write a similar post on how Rust is also a harbinger of a new wave of languages that are trying to replace C++, but make it easier to write correct code than to write incorrect code. (C++, alas, makes both quite easy, and makes it hard to tell which is which. It is true that correct code is possible, but it takes more skill to get there than it should.) Nim, for instance, fits into this mold, though a great deal less popular. I expect more. The dependent type community is also struggling mightily in the direction of putting this sort of thing out, and I wouldn't be surprised to see something moderately practical pop out in about 5 years or so.

I know the narrative right now is that Rust and Go are in some sort of fierce competition, but personally I see a world where they live in harmony, with a great deal less overlap than most people currently see, just as Python would still not displace C even if it were in fact 25 times faster.

It's really quite an exciting time and I can't wait to get my hands on these languages. I am ready to leave C and C++ behind. Of course I've already got Go in hand, but I look forward to Rust. (As I am personally a "cutting edge" but not a "bleeding edge" sort of guy in language choice, Rust and I are not yet a match. I consider this just a matter of time.)

All just my opinion, of course. I am not the keeper of the term "scripting language." YMMV.