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.
The “bypasses” your first link talks about are mostly ways of telling the compiler about types. If I make an HTTP request, how is TypeScript supposed to know of the return type of some arbitrary API? That’s where
as Foocomes in. If that makes a language not type safe to you, then you must also throw out the types in Java’s variable declarations.Quite a few more of these ‘bypasses’ fall into the category ‘garbage in, garbage out’. If you declare a string index on an object that does not, in fact, return a value for every string passed, what do you expect the compiler to do about it? This is easily fixed by declaring the proper type
Partial<{[key: string]: T]>.If you declare a variable as an Integer and then let the database driver write a Person reference into that variable, Java will fail in the same way.
Some of these bypasses are just lies, like “delete operator - Remove required properties”. You cannot delete a mandatory property from a type.
One thing I grant you that I was reminded of while reading that article is this: Some constructs are simply not expressible in TypeScript (that I know of). For instance, an object that serializes to valid JSON. That could be used to introduce type-unsafety (or whatever the correct term is).
From your second link:
Thanks for disproving yourself, I guess.
The medium article contains good examples, if a bit contrived. Thanks for digging that up.