I hate this dichotomy about hated and unused programming languages

Published on 20/09/2025

Preface

I think most of the software developers have heard this famous quote:

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

It's usually attributed to Bjarne Stroustrup (the creator of C++). The quote definitely shows that people will always criticize the programming language, no mater how popular it is, because programming languages are not ideal and also because of different tastes, edge cases, conflicting tastes, visible warts, etc. The more popular it gets, the more will be complaints.

I can't even count how many times this quote was used as a defense during "holy wars".

What's wrong with this quote

This seems like an universal answer to every criticism, right? Actually, popularity isn't always a proxy for good design. Popularity is multifactorial:

• Default platform slots. JavaScript on the web; SQL in databases; Swift / Objective-C on iOS. You don't pick the language so much as the platform picks it for you.
• Network effects & ecosystem. Python's libraries, npm for JS, JVM for Java / Kotlin. Tooling, packages, and community often outweigh language elegance.
• Corporate backing & inertia. Java, C#, COBOL in big orgs value stability, talent pools, and long support windows.
• Interop & legacy. C as a "portable assembly" or languages that talk well to C win by plugging into existing code and OS APIs.
• Education & hiring. What universities teach and what recruiters ask for matters.
• Timing. PHP "won" early web hosting because it was dead simple to deploy. TypeScript rose when JS apps got big enough to make types a relief.

While virtually every popular successful programming language will get some criticism, some languages will get it much less compared to other languages with comparable popularity. For example, C# is a very popular language, but you don't hear as much complaints about C# compared to JavaScript or PHP. Most of its criticism is mostly about GC / runtime trade-offs, language growth, and tooling edges instead of poor language design (that JS, PHP and some others get).

Early "flawed" designs still win

Older programming tend to be more popular, sometimes largely from historical reasons. Some of them didn't succeed because they were carefully designed, they succeeded because they shipped fast, got bundled with a dominant platform, and then adoption snowballed despite design warts. Later, those warts were mitigated (at least partially) with crutches (add-ons, modes, or tooling) rather than clean breaks.

Here are examples:

• JavaScript (1995): a 10-day prototype glued into the browser. Adoption came from default distribution, not careful design. Decades of patching followed: strict mode, modules, let / const, classes, promises / async, TypeScript, eslint, bundlers.
• PHP (mid-90s): dead-simple deployment on cheap hosts made it explode. Later came Composer, namespaces, scalar types, attributes, static analyzers (Psalm / PHPStan), frameworks (Laravel) compensate the rough edges.
• C / C++: became a system programming language via portability and ABI gravity. C++ kept accreting features to cover gaps (RAII, smart pointers, move semantics, modules, ranges). Powerful, but complex because of backward compatibility.

Here are examples of more modern and relatively well designed languages:

• Go: small spec, one toolchain, opinionated simplicity. Fewer footguns out of the box. Trade-off is minimalism.
• Rust: ownership/borrowing and explicit lifetimes make safety the default; steeper learning curve, but the design goal was clear from day one.
• Kotlin / Swift / Dart: non-null by default (or sound null safety), ADTs / sealed types, powerful inference, structured async / modern ergonomics baked in.

Conclusion

Here I'm not claiming you should use only the "latest and greatest" tech. As mentioned, there are other factors as well. I'm just claiming you should't use Bjarne Stroustrup's quote as an argument since it's actually a witty half-truth, not a rule. Newer programming languages, while not flawless, tend to not repeat the past mistakes of older programming languages.

Also, there are true tradeoffs, for example, a more flexible / dynamically typed language might be better suited for rapid prototyping but not so much for large and complex projects and vice versa. Thus, sometimes it's not the fault of the tech stack, it's just the wrong choice for the given problem.

Happy coding!