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.
“Blame the author, not the language”
Says the person who screams they have never worked professionally with a team before.
There is no excuse to not use statically typed, safe languages nowadays. There are languages that let you build faster like Python and Typescript, but faster does not mean safer. Even if your code is flawless it still isn’t safe because all it takes is a single flawed line of code. The more bug vectors you remove the better the language is.
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.
If there is a single flawed line of code, the code isn’t flawless.
Even if the code is flawless now, all it takes is a single flawed line of new code. This is of course true for all languages, but type safety helps a lot as some types of flaws would not compile.
In my 15+ years of experience many of the actual field problems are not language / programming related at all. Unclear requirements or clear but stupid requirements cause loads of issues. These are often caused by communication problems between people and / or organizational issues.
It depends a lot on the industry of course. For embedded software, low level networking etc I mostly agree with you. However, in business applications or desktop applications it’s from my experience mostly bad requirements / communication.
Don’t forget to add incompetent leadership to that list. If feature needs to be shipped by some arbitrary deadline and the engineers are forced to rush through the design process, you end up with a patchwork hack of tech debt that leads to more tech debt.
There are definitely use cases where something like C is still the best option because it’s faster. For the most part consumer software it’s unnecessary, but it’s not obsolete for all applications.
Hell, assembly code is still necessary for the lowest-level init code. Once you have a functional stack and some var init logic you can graduate to C.
A little hair-splicy, but an assembly-free bootloader is definitely doable on some platforms – Cortex-M processors load the stack pointer from the vector table, and the initialized memory setup can be taken care of with memcpy.
True, but you’re not gonna be setting the access levels or doing anything else with control registers on a Correx-M in pure C, let alone boot to a safe state with zeroed registers.
That’s ridiculous. Everyone knows its best to write modern bootloaders in Matlab.
You joke, but my first “lets make facebook, but…” comment was from an electrical engineer buddy that wanted to use matlab. That was the whole pitch. “Facebook, but matlab.”
It did not go far.
Real men use Scratch for everything.