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.
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.
I am not arguing against type safety, just pointing out the glaring contradiction in defense of it.
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.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.
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.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.
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.
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.
Yeah, if your bootloader is expected to handle that you’re going to need assembly. That can also be delegated to the kernel, RTOS, or bare metal reset vector later on in the boot sequence, though. I had to write a bootloader for an embedded system like this once and it basically just applied firmware updates, validated the firmware, and handed control over to the firmware.
You’re just describing more components that are written in C and assembly.
My point is that assembly isn’t strictly required. You can do memory-mapped reads and writes from C all you want, which is enough for plenty of I/O: storage, serial, sensors, GPIOs… You can build quite a few things with these without touching system registers.
I’m not saying we should abolish assembly. Just that it isn’t a universal requirement.
My point is that there’s still gonna be some somewhere. You’re just trying to handwave it away because somebody else wrote it.