"The Mess We're In" by Joe Armstrong

Luddite is someone who is opposed to new technology, which doesn't apply here as the sentiment isn't about being opposed to the new tech but about the new tech not being taken advantage of. The software we build today is "vastly" more powerful in the sense that, strictly speaking, you can do more stuff, but it is way less powerful - and often broken - than what it could be, considering what you can see being possible on older hardware and what seems to be done in modern hardware. Also it isn't really something that happens today, here is a nice (and funny) talk from Joe Armstrong on the topic from almost 8 years ago[0]. Though this sort of sentiment goes way back, e.g. Wirth's classic "Plea for lean software" article from 1995[1]. (Joe's talk is more about the broken part and IMO he misidentifies the issue being about trying to make things fast when the real issue -that he also mentions- is that pretty much nobody knows what is really going on with the system itself) [0] [this video] [1] [link]

I saw Joe's strange loop talk [1] a while ago and I get the same vibe reading his post as I did when watching the video. It sounds very cool, but I can't shake the feeling that it only works for 85% of the code. That is to say if you program in exactly the right way, you will be able to do everything you want and it will work with this system, but there are ways of programming that won't work with this system. More specifically I feel like there are two problems. 1) It feels suspiciously like there's a combination of halting problem and diagonalisation that shows there are an uncountably infinite number of functions that we want to write that can't be named (although I would want to have a better idea of how this is supposed to work before I try to hammer out a proof). 2) I don't understand how it's possible for any hashing scheme to encode necessary properties of a function such that the function with necessary properties has a different hash than an otherwise identical function without these properties. For example can we hash these functions such that stable sort looks different than unstable sort? Wouldn't we need dependent typing to encode all required properties? And if that's the case couldn't I pull a Gödel and show that there's always one more property not encodable in your system? [1] - [this video] [2] [2] - [link] (thanks for the link)

Lets not forget that the usage of javascript correlates with need to target the omnipresence of browser and not for merits of javascripts idioms or design pattern paradigms. Javascript is a great hacker language. All the improvements as stated above will extend the capacity of js to quickly hack up mvp apps. With that said I think the argument can be made that javascript was never designed from the ground up to support this new omnipresent realtime persistent application platform. For me the question remains to be seen answered if a server that was designed the ground up to be a server such as netty offers a more stable solution then node.js I think some might say that ES6 is like putting lip stick on a pig therefore patching up JS to keep evolving as more expressive language. Every time I run NPM install I wonder what kinds of incidental complexities I am I getting myself into. Then dred if I have learn yet another build system. Every time I run NPM I think of an old Jim Breuer joke [1] -- NPM is the "tequila" in the JS party of complexity. ASM.js is amazing, but are we getting a little too drunk on our technologies. ASM.js just might be amazing koolaid when it comes to the sobering decision to build something from "the feet up" to serve on purpose and serve it well. JS can be the jack of all trades and master of none and that can be a bad thing. One thing is for sure JS is really fun, but I would not go making a stock market exchange out a javascript codebase. Speed is not

I'd say your comment is not constructive: you're asking me to name all the solutions, otherwise my observation has no merit? I'll expand a little. Let's take a single example: developing a single page web application. To know how to do that, I need to learn HTML, CSS, JS Frameworks, web pack or whatever. Linters, preprocessors, package management .... Contrast that to building flash app where a designer could use a GUI to produce a beautiful interactive app in no time at all. Yep, we all hated Flash, but in terms of accessibility to creators, it was beautiful compared to the mess we've made. A little off-topic but good for perspective: [this video]

Thanks for the Paper! I'm looking forward to spend my weekend with it. Normally I'm a huge fan of a philosophy of backwards compatibility. Clojure has shown that it is possible with enough dedication. But I feel like it's a liability with the lineage you describe for Rust, the problem space was just too unexplored and vast, and the language has grown too large. Joe Armstrong has a joke in one of his keynotes [1], that after you've written the first version of something you should throw it away completely, because you didn't understand the problem at all when you wrote your solution, and now you understand it a bit better. A bit like how the web would be a much less ghastly ecosystem if we hadn't abandoned versioning for living documents which force every behaviour ever to interact, and god forbid be compatible, with one another, in a combinatorial hairball. Modern browsers would be less unwieldy if they just shipped 30 different rendering engines, one for each major revision, than ship a blob that purportedly is able to still render everyones Dogs website from the 90s (which is not true of course, it's just that nobody from the 90s is here to complain). It's a bit ironic that Rust fell into the same trap that caused the complexity that inspired its inception in the first place. Maybe once the major "features" for safe system programming were identified a new language (revision) should have started with only those features at its core. I fear that if such a language were to cr