Thread by @isntitvacant

one of the fascinating things about "coders at work" is being transported back to 2009 and seeing the preoccupation with "our multicore future" at the time

and then looking at the present day and connecting dots.

my hot take^W^Wread is that:

- python, ruby, js, and java are "of a generation" of programming languages (say: 3rd gen)
- well-resourced companies went heads down and sought to address 2nd/3rd gen issues with a new generation of PLs
- meanwhile, js

(in retrospect I think node's success may have been surprising – lengthening the relevance of the 3rd gen of languages in our "multicore future". The 32X to JS's Sega Genesis. It couldn't do threads, but it did make it ~easier to make efficient use of existing resources)

I focus on this because a common thread in the interviews thus far is that we need a safer language with great multicore support; and that _maybe_ software transactional memory will save us

node is none of these things!

we've popped out, a decade later, with a new generation of programming languages (rust, golang, swift.) The common themes seem to be traits-over-C++-OO, checked returns vs. exceptions, and robust concurrency stories

this puts node (& js) at an interesting crossroads. for as much as JS differs from, say, Java or C++, it's still very much a product of the 3rd generation of languages and some of those concepts are baked really deeply into the language (exceptions!)

typescript might be able to give it another ten years? I don't know. JS has eaten the world, but cracks are showing: error handling is Bad, app bloat is a pervasive complaint, and our options for threading are limited. WASM is one way out.

(re: threading: JS worker threads are A Thing now, but the mechanism for "moving" data between them is a pretty narrow channel – event passing and/or direct transfer of certain kinds of data structures. Startup costs aside, they don't seem fundamentally different from multiproc.)

Re: error handling: it is bad in javascript, and it is not javascript's fault in particular. JS has the popular 3rd gen error model (exceptions!) Exceptions are... not great. (I sigh, as a former Python programmer.) Promises exacerbate this situation.

(Error propagation is important. You want the programmer to check every error, and explicitly propagate errors. Exceptions make propagation the default, and it's a bad default: errors aren't exceptional! They're a huge part of our job!)

I note, from a conversation with a co-worker, that Java-the-platform survived longer than expected in the multicore future on the strength of its concurrency primitives. It just happened to be other JVM languages that capitalized most on this — Clojure, Scala, etc

Anyway – it's fascinating that JS took the world by storm in the last decade, despite the industry focus being on safe, multicore programming. Multiproc was good enough. Exceptions were workable.

Will that be true in 10 years?

(After a brief exposure to Rust, I already kind of dread working with the error handling tools that JS gives me – it's like chopping veggies with a dull knife. Workable, but it takes a lot of attention.)