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.
I agree with the post. Setting up typescript takes an hour or two if you have no clue what you’re doing. In return you get the absence of (the equivalent of) null pointer exceptions.
I chuckle every time I find an NPE in the Java backend. Doesn’t happen to me. Can’t happen to me.
Sidenote, while I’m already gloating: Once the backend code had an error where they were comparing two different kinds of IDs (think, user ID and SSN), which gave wrong results. This error can’t happen to me either, because I type my IDs such that they are not comparable. A strong type system really is a godsend.
NPEs are the reason why my team moved to Kotlin. Well, that and all the other myriad advantages Kotlin brings to the table.
Modern versions of Node.js have native TypeScript support. For scripts, you can just write the script then run it. That’s it. No build process needed. A beginner could just rely on type checking in their editor (I think VS Code has the TypeScript tooling installed by default?)
For web apps, just use something like Bun or Deno. Bun gives you practically all the tooling you’d need (JS runtime, TypeScript, package manager, test runner, bundler, and framework for building web apps) out-of-the-box. It doesn’t have a formatter, but you can just use your editor’s formatter.
Recently I’ve just been getting co-pilot to do it
I have an alias that calls the copilot CLI with a prompt that says “set up typescript”
Fuck this