I'm going to have a little thread here about platforms, inspired by Ryan's release of deno. [Thread]
The release of a new platform is innevitably framed by everyone as a disruption to existing platforms. This zero sum view of platforms is true in the personal sense, most people choose one platform over another, but is entirely incorrect in the macro sense.
Tech, and Open Source, are growing at such a fast rate that many platforms can be growing and gaining adoption in parallel. One platform succeeding never means another platform dies.
In absolute terms, more people use Fortran today than at the height of Fortran's market share.
In absolute terms, more people use Fortran today than at the height of Fortran's market share.
Next, in the Macro sense, every new platform is a value add. I just haven't seen a platform or programming language that didn't teach us all *something* new.
We should celebrate basically any additional to this landscape.
We should celebrate basically any additional to this landscape.
As an example, I occasionally make fun of Haskell because of their allergy to anything that might get them broader adoption.
At the same time, I learned Haskell many years ago and didn't really understand functional programming until that point.
At the same time, I learned Haskell many years ago and didn't really understand functional programming until that point.
Haskell was the first language I used that didn't compromise, ever. As a result, it forced my brain out of more established and comfortable pathways until I got a much more solid understanding of functional programming that is useful to this day in writing other languages.
Often, platforms are presented as winning or losing based solely on adoption. This doesn't capture their influence on other platforms that do attain broader adoption.
The two most influential languages in history are Smalltalk and Lisp, both of which never gained broad adoption.
The two most influential languages in history are Smalltalk and Lisp, both of which never gained broad adoption.
Moving on, I think there are two solid pathways to created a successfully adopted platform.
Option 1: Bootstrap on an existing ecosystem. Be highly compatible, but add a lot of value. Best example today is probably Webpack (yes, webpack is a platform).
Option 1: Bootstrap on an existing ecosystem. Be highly compatible, but add a lot of value. Best example today is probably Webpack (yes, webpack is a platform).
Option 2: Be as incompatible as possible. Be so new that you have to everything new, from scratch. This attracts people that live for being the first to write "that thing" I your platform.
This was Node.js' strategy but Go is probably a better example.
This was Node.js' strategy but Go is probably a better example.
Node.js was incompatible with most C libs because they used blocking IO, and was incompatible with almost all JS at the time because there was no DOM.
But Go went even farther, no libc dependency, everything ever had to be written from scratch.
But Go went even farther, no libc dependency, everything ever had to be written from scratch.
The benefits there are clear. Node.js will never have TLS perf comparable with Go because binding to OpenSSL aren't ever going to beat Go's native crypto. Go is also much more portable because it has zero shared library dependencies.
Looking at deno, my primary concern is that it falls somewhere between these two options. It takes steps not to bootstrap on the npm ecosystem but, because it is Typescript, is just a fancy compiler away from that possibility. Reminds me of JVM languages a little.
Anyway, moving on, let's talk about the other edge of the double edged sword of adoption: compatibility.
There is no roadmap, no plan, that can dictate the point at which you have to support a bad decision forever. Pressure from adoption does that for you.
There is no roadmap, no plan, that can dictate the point at which you have to support a bad decision forever. Pressure from adoption does that for you.
Ryan's regret list for Node.js is interesting in the context of the project's history.
The original plan was to liberally break compatibility until 1.0 but as of 0.2 too many people depended on API we couldn't change.
The original plan was to liberally break compatibility until 1.0 but as of 0.2 too many people depended on API we couldn't change.
Many of these "regrets" probably would have been changed by Ryan between 0.2 and 1.0 had his plan stayed viable.
But adoption was too dramatic, people were running real production workloads at scale already, we couldn't go breaking things without causing massive backlash.
But adoption was too dramatic, people were running real production workloads at scale already, we couldn't go breaking things without causing massive backlash.
In contrast, Rust was released the same year as Node.js but adoption has been slower and more gradual, rather than the exponentially adoption of Node.js.
This has let them fix mistakes they couldn't have fixed if they had seen faster adoption.
This has let them fix mistakes they couldn't have fixed if they had seen faster adoption.
As a result, Rust has a cleaner and more consistent feel. You are presented with the history and compromise of the API far less than Node.js.
The tragedy is, adoption breeds adoption, the network effects multiply incentives.
The more adopted a platform the less consistent the API will be, the more warts, etc. The best you can do is keep stdlib small so that you have less opportunity for inconsistencies.
The more adopted a platform the less consistent the API will be, the more warts, etc. The best you can do is keep stdlib small so that you have less opportunity for inconsistencies.
Lastly, I think that deno is interesting but not as interesting as new platforms that are more targeted at a specific vertical. Webpack has certainly reframed for me what a platform can be.
It makes sense that we might see other verticals, like cloud functions, get their own too
It makes sense that we might see other verticals, like cloud functions, get their own too
And WASM is going to open up a crazy amount of opportunities for new and more constrained platforms we haven't thought of. I'm not even talking about new langs in browsers, this is the first standardized low level compile target, that has far ranging potential beyond browsers.
