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 have to write so much boilerplate code to make sure my objects are of the correct type and have the required attributes! Every time I write an extension for Blender that uses context access, I have to make sure that the context is correct, that the context has the proper accessor attributes (which may not be present in some contexts), that the active datablock is not None, that the active datablock's data type (with respect to Blender, not Python) is correct, that the active datablock's data is not None... either all that or let the exception fall through the stack and catch it at the last moment with a bare
exceptand a generic error message.I used to think that static typing was an obstacle. Now I'm burning in the
isinstance/hasattr/getattr/setattrhell.I loved python when I was a junior dev. Now I hate it (except for things like computational math). I have to add debug statements to figure out that someone snuck in the wrong type into the code.
Type checkers are your friend if you can enforce them. I’ve started using them in my new projects and find that they make those types of bugs harder to sneak in, especially if you’re strict about requiring type hints/definitions in your functions and classes.
I like
ty, but it’s immature. Check out Pyright as well.That is the trap that, sadly, my company fell for too. The POC was written in python. very fast i might add. but it was only that: a POC. if the whole backend crashes due to unexpected user input - noone cared. if the frontend displayed gibberish because the JSON made wrong assumptions about not defined data types - sweep it under the rug, don't do that during presentations.
but if it came to building a resilient system, which can be shipped to customers and preferably maintained by them (with minimal consulting contract for access to our guys)... we cursed the way python worked.