I agree with his main thesis which is that we can do better to improve on some of these literally 60 year old programming and programming tooling paradigms.
I'm hoping that the paradigm improvement isn't to just paste over the entire endeavour with some AI agents that abstract away coding as we currently think about it.
I mean, by that logic, languages like Rust and Golang should never have taken off. Yet we see improvement due to their invention and adoption. Limiting programming language design and theory will rob us of a lot of potential improvements we could achieve at some point.
Possibly? I mean, for certain kinds of systems (most of the CRUD stuff out there) having some boring technologies and frameworks that are fairly stable and get security updates is probably preferable, even if they're not the most modern or stylish to use. And since the Lindy effect seems to have some truth to it, those might also help with picking something that will probably still be around in 5-10 years.
Think Java with Spring Boot, C# with ASP.NET, Ruby with Rails, Python with Django, PHP with Laravel, Node with Express.js and so on.
> I mean, by that logic, languages like Rust and Golang should never have taken off.
In my country, they mostly haven't. Most of the job postings are for the languages and frameworks above, there's actually very little in the way of modern tech stacks, so it probably depends on where you're located - tech hubs (or idk, research in academia) will allow for shinier technologies vs something more boring and conventional!
Also, old languages can be improved still. Java has some gotchas that will probably forever be fossilized into the language, but it still managed to get algebraic data types, proper pattern matching, virtual threads, etc.
Also, add to it Brook's famous paper and we can see that "new, modern" language will fail to account for even single digit productivity improvements, let alone order of magnitude differences. Me adding an already working, battle-tested dependency is the only real productivity booster.
(Nonetheless, I'm absolutely not against change, and I absolutely love language design as a topic. I just think that any language that wants to live in its own hermetic world has to give a really good reason for that choice)
Good libraries for everything commonly done server side in web dev. Google people write the libraries, and they're used within Google, so even the obscure cases are executed frequently. If your problem is a variation on a common theme, not only can Go probably do it, common LLMs will know how to make Go do it.
Go gives up a little performance in exchange for simplifying some problems that give many programmers trouble. It's garbage collected, which simplifies ownership, and its goroutines can safely block, so you don't have the async/sync distinction. Since LLMs don't really understand either of those issues, this makes LLM-driven coding work better.
Remember, LLM based coding is about as good as copy-pasting from Stack Overflow. It only works well in areas where there's something it can copy and mod. Usually, if you search for names in LLM-generated code, you can find where it located a prototype to copy from.
Java is also GCd with significantly better implementationS, they have far better throughput, and they also have a low-latency one where pause time is actually decoupled from heap size, unlike what Go does with simply blocking threads under load.
Also, Java has virtual threads which are the same as go routines, so not even that is a relevant difference.
And due to it being a bigger language, more of it will be found in LLM data sets, ergo LLMs will more useful in case of Java.
Anything of decent value and well design will be adapted and continue to be built. But anything without decent marketing power will die anyways regardless and only get adapted because it felt cool to that random engineer no.1 who wanted to pad there CV quickly before jumping onto next big money machine.
Show me the mass adaptation of Nim/F#/Scala(decently mature)/Crystal/Odin etc and I’ll understand your points.
Go is a different league compared to the ones I mentioned.
But Go wasn't really the point of the article, so maybe we shouldn't be here doing language flamewars? :D
Nevermind getting a newer language with new useful concepts, can we just have a tooling ecosystem that isn't broken!
I would suggest trying a different ecosystem entirely. I chose Go's, but there are many alternatives not nearly as broken, and in some cases working quite nicely.
I’ll admit Go and Typescript come close though.