Post:
If you’re still shipping load‑bearing code in C, C++, Python, or vanilla JavaScript in 2025, you’re gambling with house money and calling it “experience.”
As systems scale, untyped or foot‑gun‑heavy languages don’t just get harder to work with—they hit a complexity cliff. Every new feature is another chance for a runtime type error or a memory bug to land in prod. Now layer LLM‑generated glue code on top of that. More code, more surface area, less anyone truly understands. In that world, “we’ll catch it in tests” is wishful thinking, not a strategy.
We don’t live in 1998 anymore. We have languages that:
- Make whole classes of bugs unrepresentable (Rust, TypeScript)
- Give you memory safety and concurrency sanity by default (Rust, Go)
- Provide static structure that both humans and LLMs can lean on as guardrails, not red tape
At this point, choosing C/C++ for safety‑critical paths, or dynamic languages for the core of a large system, isn’t just “old school.” It’s negligence with better marketing.
Use Rust, Go, or TypeScript for anything that actually matters. Use Python/JS at the edges, for scripts and prototypes.
For production, load‑bearing paths in 2025 and beyond, anything else is you saying, out loud:
“I’m okay with avoidable runtime failures and undefined behavior in my critical systems.”
Are you?
Comment:
Nonsense. If your code has reached the point of unmaintainable complexity, then blame the author, not the language.
NPEs are the reason why my team moved to Kotlin. Well, that and all the other myriad advantages Kotlin brings to the table.
I like the “advantage” that using any Kotlin code in normal Java automatically forces you to use the kotlin-stdlib for Java 8 and adds a additional bloat of 10MB to your project…
10MB? Oh no! How is this going to fit on my 1TB drive?
Well, ideally you start new projects writing 100% Kotlin while only adding Kotlin code to older codebases you can’t get rid of. Personally, I don’t like mixing languages anyway and I would stay with Java in Java projects. One reason is the bloat argument you pointed out quite correctly.
Ohhhhhh noooooooooo, not my 10 mbs
Lombok had a bunch of great things that should’ve been part of the java language to begin with. They’ve slowly been folded in (so now you have to work out which @NotNull annotation you want) but the language does still improve.
True… but Kotlin makes Lombok quite unnecessary by having its concepts built in. It’s also worth to point out that null safety is opt-in in Java and opt-out in Kotlin.
That’s a good point. You can get away with that with a new language, but adding nullability as a non-default option would break existing code much like making things const by default in C++ would, I suppose.
One of the backend devs started using Kotlin. From time to time I need to read backend code, and I have to say it’s very easy to write an incomprehensible mess in Kotlin.
Kotlin isn’t perfect and it gives the devs quite a lot of freedom. I would argue that if your Kotlin code is messy, that’s on you - but it will still be significantly less prone to failures like NPEs. Unless you opt out of null safety by using the dreaded ?-Operator.
I really like how I can turn everything into immutable
val’s and represent different paths as expressions, it can IMO really reduce the complexity of a function and makes it easier to spot bugs. I’ve been migrating some code of a FOSS app to Kotlin and was able to shrink most classes by like 30% while making it easier to read. The only thing I dislike about it is the additional syntax for various things, I could do without having multiple ways to write a constructor.Yes, there are things about Kotlin I don’t love either. But I still like how it was clearly developed having developer quality-of-life in mind.