Why Programming Languages Die: It's Not About Technical Merit

Because It's Not Fun Enough: why languages fail

Why Programming Languages Die: It's Not About Technical Merit

Andrew Oram's series for the Linux Professional Institute sorts languages into immortal, respectable, and failed, but the real insight comes from Simon Peyton Jones: adoption is weakly tied to technical merit. This piece argues that languages die when they make one of three human needs—vocation, art, or job—needlessly difficult. JavaScript survives despite being an art failure; Objective-C thrived until Swift arrived; COBOL persists only because replacement is costly. The distinction between difficulty that pays off (C++, Rust) and friction that doesn't (Ada, COBOL) explains why some hard languages thrive and others fade.

Languages don't lose benchmark fights. They lose people.
  1. jillesvangurp

    There's more to a language than the syntax. The libraries, tools, and the ecosystem of developers, documentation, support, etc. are much more important. There are quite a few academic languages that are interesting to people that never really gain much traction because the people behind them just never commit to proper ecosystem building.

    Switching languages is a big time commitment. Or at least it used to be. I find myself more open to that now that I can hit the ground running with AI coding tools in most languages. But still, it's a time investment to learn a language, its idioms, its way of doing things, all the tools, libraries, and frameworks, etc. It's not something you do an in afternoon. And certainly not mid project.

    The languages that people gravitate to are the ones that look like they are safe, future proof bets. If you are going to spend all this energy learning one, you want to know it's a good investment. Successful languages have lots of users, decent tools, good libraries, etc. Or at least they look like there are serious people behind them. Many people make these bets early in their careers and then stick to them as well. I meet a fair share of people my age that are still sticking to Java. Because that's what they learned when they were in their twenties. I'm 51 now.

    Rust is a good example of a language that's hard to learn but managed to get off the ground because of the solid people behind it. It wasn't just an academic exercise: Mozilla was trying to so […]

  2. thataccount

    I'm calling bull on this. Learning languages, at certain points, is always tedious. Whether that language is a computer language, or something like Greek, there comes a moment where "trudging" begins. The reason a person "trudges" is that they have a goal in mind that makes the trudging something to endure until that goal is achieved. Fun comes from not having to solve the same problem sixty times, or having to sort through a million files by hand when a program can do it in 3 seconds.

  3. Zak

    I was hoping it would address Lisp.

    Lisp is fun. The interactivity and instant turnaround of a Lisp REPL is still rarely matched in other languages. Common Lisp also solved a significant issue other languages didn't address well until much later: the ability to write high-level code that was fast on cheap hardware around the turn of the millennium.

    Lisp didn't get popular around the turn of the millennium. Success stories like Naughty Dog, ITA, and Viaweb were rare, and the dominant languages seemed to be Java and various scripting languages starting with the letter P.

  4. mojuba

    Yes to all that but still, my pet theory is that languages rise on one or two "killer features" that move the entire industry forward, and not the overall cuteness or lovability.

    I can suggest a list of one killer feature per each popular language, i.e. things that these languages were the first to introduce and influence many successors:

    C: extreme conciseness

    C++: implicit destructors / RAII

    Python: removed curly braces

    Java: extreme portability

    JavaScript: erm...

    PHP: embedded in HTML by design

    Rust: compile-time memory management

    Swift: structured concurrency (pre-6 was probably just pure cuteness)

    etc.

  5. rzwitserloot

    To add a few more exotic cases that affect things. Keep in mind that by default new languages fail. To succeed, many things have to all go right at once, and this implies that therefore there is not one single element that, if gotten right, means the language will therefore be successful (it's rather the opposite: If even one of the key factors is wrong, it'll probably fail).

    * It's just a guesstimate, but one of those factors that caused java to be successful but-for (as in, if it hadn't had this, it wouldn't have been a success): It copies C style religiously anywhere it could get away with it. This caused some damage to the language that it has fixed in the past decade (such as the style and behaviour of `switch` being so bizarre - but it religiously follows exactly how it works in C!)

    * Some languages end up failing partly due to community outlook. Scala is somewhat well known for having a core community that is highly aggressive and elitist, or to be a bit milder, to be 'less accepting of newbies with a limited understanding of programming concepts' than is optimal'. And in addition to that, they are in contrast to the java ecosystem ready to drop support for stuff quickly, meaning: Real life actual use of scala as a basis means you're either working with a hopelessly obsolete codebase or you're spending time refactoring it every other month pretty much. Scala's adoption is fading and never got anywhere near its hyped future.

    * If a language is 'native to a platform' wh […]

  6. asa400

    Unfortunate how many languages with interesting stories were either glossed over or omitted entirely.

    Clojure was an outright revolution against Java’s boring clumsiness, and many businesses are quietly making money with it today. Hickey even _explicitly_ comments on expertise (the OPs discussion about Rust and C++ being worth it) in the context of learning to play the violin.

    Ruby declared itself as being all about “programmer happiness”, and while probably not as specifically a rebellion against Java, it attracted a ton of burnt out Java people who went on to found thousands of startups on Ruby. Ruby continues to be massive for web apps, Rails is still extremely popular compared to many alternatives.

    Scala similarly to the previous examples was a Java-like with Haskell flavor that escaped an academic lab and accidentally took over the “big data” craze in the 2010s because they wrote Spark in it. If you were around then, Scala was truly hot at the time.

    There are others of course but I found the examples in the OP a relatively surface level analysis of a space that has experienced an absolute explosion of diversity and novelty in the last 20 years.

  7. nyeah

    >That quote is the article, and it's a little surprising that it's buried so far into the content

    Is it really surprising in 2026? Today's online writing style is not primarily designed to communicate. It's designed to keep the reader 'engaged' for as long as possible. The reader's time is a resource to be extracted.

    I'm absolutely not poking this author individually. It's the writing style of the net

  8. npn

    Agreed. I think people tend to forget that:

    you do not have to pick a single language. it is trivial to use another language just for that single library. there are many way to communicate, it is not like method calling is always the hard requirement

    since you do not have to choose a single language, the killer feature of that language is mostly useless, even if there is no other language that have the similar feature, people would just write a some glue code to bridge it with their main codebase. and usually, there is no such thing at unique feature that only that a single language can have. sure, it can be achieved easier in that language for some use case, but even so, a single bridge file is probably enough. aka nobody would invest in your language.

    writing software is mostly using other people libraries anyway. the thing we write the most is some common business logic, thus the syntax is extra important, or rather, the DX is the most important thing. heck if the experience is great enough I can throw thousands hours to write the libraries/frameworks myself, it is (usually) not that hard.

    it always turns me off seeing a new introduced language that syntax wise is a carbon copy of rust or C. no thank you, if you not even want to think about the syntax, why should we believe that you can deliver something truly innovative?

More from this day

2026-08-10