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.
If the language makes common but dofficult to deal with error impossible, that's nice. Not critical, but nice.
If the language introduces easy to make and hard to deal with errors, that's an issue. Not a deal breaker, but an issue.
The idea does exist, but it's stated with way more confidence and finality than it deserves. That's social media I guess.
I still don't accept the fundamental core point of the arguement which is that rust necessarily makes it impossible to commit certain errors. Rust has its rules as such as only programming language does but that doesn't mean that mistakes are impossible.
The vast majority of errors are logic errors not memory leaks in standard functions.
Memory leaks are often difficult to deal with, and many contemporary languages basically encourage them. I know many applications that suffer significant performance issues due to memory leaks, and way too many that simply don't care about memory footprint.
A language that treats memory management differently from the start makes all these problems much easier to deal with, if they appear at all. The real question is if the other costs of using the language are worth the somewhat niche performance gains.