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?
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.
There have been multiple operating systems written in Haskell
I believe you and I'm sure they were fine.
I wrote an XML parser in LabVIEW once. Just because you can doesn't mean it's the right thing to do lol.
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.
Not necessarily. Let's say that...
_entry(), with a linker script to take care of its memory placement.You can compile only your C source file that defines
_entry()and interrupt vectors, then flash the resulting firmware. No assembly involved, no external linkage, and no stdlib required.Yes, and this is ignoring interrupts, access privileges, thread stacks ... what's the C equivalent of the MSR and MRS instructions?
Again, those aren't universally required. You can make an embedded device that reads the ambient light levels and turns on an LED when it's dark without thread stacks, privileges, or interrupts. Don't make your system more complicated than it needs to be.
Turning on an LED when it's dark doesn't require a microcontroller, let alone a Cortex-M. You can accomplish that with analog electronics.
Anyway, you're moving the goalposts all over the place. What happened to the RTOS kernel from earlier?
Not moving the goalposts at all, you're just missing the forest for the trees. The main point is that there are plenty of use cases that can use pure C with no assembly. I went with a simple example because I thought you'd have an issue with more complex examples like sending a notification over SMS via modem or providing a serial interface for sensor data.
I don't feel like arguing for the sake of arguing, though, and I feel like we're in a pedantry spiral, so I'll leave the conversation at that. Hope you enjoy your day.
You're the one who decided to start splitting hairs. Flounce on away.