Thread by @mikeal

Node.js, Go, and Rust were all released within a year about 9 years back.

Here's what I remember about that time.

There had been what seemed like an explosion of new platform languages and then a contraction. Perl and PHP felt like they had given way to Python and Ruby although Ruby was the star at the time, Rails was really taking over.

There was a sense that there wasn't really space for new platform languages and VMs.

A new JVM language would come out every few years and then slowly fade away.

One thing that is striking looking back now, JS was just not talked about. The web was huge, JS VM's were competing and getting remarkably fast, but all of that was separate from "real programming."

If you think web developers are treated 2nd class today, they were 4th class.

2009 was the *first* JSConf. There had never been a conference focused on JavaScript before that. @voodootikigod started it with the explicit goal of moving past this "toy language" nonsense.

Anyway, back to platform languages.

All the dominant languages at the time had grown up in the hayday of linear Moore's law. Computers had one processor and it just kept getting faster. As a result, high level languages had done less than zero performance work.

Java was running big work loads and after a running for several *minutes* it was quite fast. Python was an order of magnitude slower and had no interest jn being faster and took a 50% perf hit for Python 3.

Not to be outdone, Ruby was even slower.

Perf arguments came down to 2 positions:

* Performance doesn't matter cause we "optimize for developer time which is more expensive" 👈 not exaggerating, this was the dominant view of the Rails community.

* Anything that doesn't do processing parallelism is futile.

The first position is comical in hindsight, but the second one shows something fundamentally missaligned with performance views at the time.

IO concurrency and processing concurrency were lumped together as effectively the same thing.

Even though all these platforms had libraries or forks that did non-blocking IO operations the mainline language and libraries did not. Since doing concurrent IO *meant* doing concurrent processing they didn't really distinguish.

Around this time, WebSockets are coming out of committee and being implemented. We're also seeing a lot more REST APIs and services built by stringing them together.

Without IO concurrency these applications were very expensive and slow. For many of us, the need was clear

Once thing to note about Node.js, Rust and Go is that all of them make a distinction between IO and computation concurrency. The way this is exposed to the developer is very different, but none of these platforms treat these as the same problem.

The reason I bring this all up now is that I fully expect another wave of platform languages.

What I don't see yet is what all of the dominant platforms are getting so wrong that these new platforms can resolve.

So far, what I've seen are specific complaints about Node.js or Go and the new platforms trying to appeal to those same users who share that complaint.

But what are *all* of them getting wrong?

What is so painful to do in *any* platform that it creates space for a new one?

People point at WebAssembly as this thing that will enable their favorite syntax on the Web, but I don't think that is going to really matter.

I think what will matter is, how well does this language compile to WebAssembly?

JS is, ironically, the worst language to try and compile to WebAssembly.

Being that JS is the market leader by every metric (active users, developers, packages, etc) that certainly creates space for a new language/platform that conforms well to WebAssembly's constraints.

The Web development work and the decentralized blockchain world haven't really collided yet. They will, it's innevitable, and that will also open up a bunch of opportunities for new platform languages.

Being good at cryptography and content addressed datastructures, will matter.

Functional languages have a big leg up in that department.

Also, Rust is already quite good at all of this stuff. It compiles well to WebAssembly, its internal data structures have many of the same contraints content addressed data imposes.

Rust, not JS, may be setting the bar.