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.
So there is apparently a problem with languages such as JavaScript and the solution is to use languages such as TypeScript.
Wut?
TypeScript and safety-critical paths should not be in one sentence.
wut ?
Why ?
Genuinely curious to learn from your arguments
It’s Javascript with types. You are still using one hundred NPM packages to do the simplest thing. Any string can be JSON. And Node is single-threaded, so if you plan to create some kind of parallel computation, you’d need to run 16 Docker containers of your Node server, one per CPU core, with NGINX or some other load balancer at the business end, and hope that your database engine won’t reorder transactions. And yeah, Docker is mandatory, because Node version in your latest Ubuntu release is already outdated.
don’t just m-dash
chat gippity
Don’t just state—regurgitate!
Maybe, but always remember LLMs are trained on real people. Some people naturally use similar styles to some LLM tica as it was stolen from them in the first place.
Sounds like they want Ada Spark and not Rust.
Go and Python and Typescript all have their own footguns.
I assume Rust is the same, but haven’t used it personally to see
Rust is the foot gun, it’s so perfect that you genuinely cannot just sit down and type out what you need.
I half way agree. I always say form shapes function. Sure you can write good code in any language. But some encourage it more then others. Ultimately it’s the programmer fault when things get over complex though
I don’t get it.
Maybe the joke is nothing complex is written in fad languages?
Maybe the joke is the discounting of peer review and testing?
Maybe the joke is the lack of devops knowledge where Python is extra steps over other scripting languages?
It seems like promotion of fad languages. When I was younger, I chased fads and lost hard. I’ll stick with C and C++. Run-time failures happen to everyone including fad languages. Here’s looking at you Rust CVE’s. Better to have loved and lost, something, something.
Just don’t do bugs. How hard is that?
According to all teams I’ve worked on.
Pretty fucking hard.
I know this is satire, But really though better languages that make various classes of defects unrepresentable reduce defects. It’s wild that such a statement needs to be made, but our industry is filled with folks who don’t critically think about decisions like these.
Like the age old advice for getting better at Smash Brothers - Don’t get hit.
My second favorite prompt, behind “Do not hallucinate”
As an embedded dev, good luck not using C
You could use Forth.
Not an embedded dev. What’s the Rust situation in the embedded world? Is it ever used?
In my corner of the embedded world, it feels like everyone is practically jumping to integrate Rust. In the sense that vendors which haven’t had to innovate for 10+ years will suddenly publish a Rust API out of the blue. And I’m saying “out of the blue”, but I do also regularly hear from other devs, that they’ve been pestering the vendors to provide a Rust API or even started writing own wrappers for their C APIs.
And while it’s certainly a factor that Rust is good, in my experience they generally just want to get away from C. Even our management is well aware that C is a liability.
I guess, I should add that while I say “jumping”, this is the embedded world where everything moves extremely slowly, so we’re talking about a multi-year jump. In our field, you need to get certifications for your toolchain and code quality, for example, so lots of work is necessary to formalize all of that.
I’ve been an embedded developer for coming up on 20 years at this point, and recently went through a job hunt. Of the three that made it to the offer stage, two used Rust almost exclusively in their embedded stack and one used Rust in their embedded LInux stack and was trying to decide if they were going to use rust in their bare-metal/RTOS stack. I ended up at on of the Rust places, though I had no Rust experience. I have to say, while I do find many parts of the syntax too cute by half, in general I’m pretty happy with it as an embedded language. My current target architectures are ARM Cortex-M7 and Cortex-A53. In general toolchain, and debugger support has been good, peripheral support has been ok but could use improvement.
Bindings have been getting added to the Linux kernel so drivers can theoretically be written in Rust
Android has moved its IPC mechanism, Binder, over to Rust
I know that some people have managed to get it working but I have yet to see it in practice. Granted, my experience in the industries is currently only what I learned during my studies and 2 internships.
In general, C is supported. C++ is sometimes supported and very few people even talk about Rust.
Rust is more of a C++ replacement, no? Rather go with Odin or Zig or C3 for systemic stuff.
You often just want to go with what’s popular, since hardware vendors will only provide APIs for select languages.
Well, and depending on the field, you may need to get certifications for your toolchain and such, so then you have to use what’s popular.
Not really. The things where C++ used to shine are usually best done in higher level languages.
Rust is a great C replacement.
Rust is more of a C++ replacement, no?
It’s fast and memory secure, so it’s good for stuff you might do in C but you don’t want to risk a memory leak or segmentation fault.
I thought more in the way of atomic dependencies and how it handles features in-language vs. in-code and reliance on toolchain vs. standalone. In short, how you as a programmer are supposed to use it.
It’s not widely used. Some car manufacturers(Toyota if I remember correctly) have started testing it. Some parts are really nice.
There is exactly one hal for i2c, spi and Io pins. As long as both your chip and peripheral driver implement against it, it just works. There are more unified abstractions in the work for things like DMA, but they are not officially stable yet.
Cooperative Multi threading can easily be integrated thanks to Async rust and executors like embassy.
All the crates that are no_std compatible can be included.
It’s not perfect, but it’s getting there.
Embedded devs have heavy gambling addiction apparently
lol. Typescript isn’t actually type safe.
Explain or be downvoted
TypeScript’s type system exists only at compile time. When your code runs, it has been transpiled to plain JavaScript and all type information is erased, so TypeScript itself provides no runtime type safety.
Any runtime safety must be added explicitly (e.g., manual checks, schema validators like Zod, io-ts, or runtime assertions), but that safety does not come from TypeScript itself.
Downvote yourself please.
The “bypasses” your first link talks about are mostly ways of telling the compiler about types. If I make an HTTP request, how is TypeScript supposed to know of the return type of some arbitrary API? That’s where
as Foocomes in. If that makes a language not type safe to you, then you must also throw out the types in Java’s variable declarations.Quite a few more of these ‘bypasses’ fall into the category ‘garbage in, garbage out’. If you declare a string index on an object that does not, in fact, return a value for every string passed, what do you expect the compiler to do about it? This is easily fixed by declaring the proper type
Partial<{[key: string]: T]>.If you declare a variable as an Integer and then let the database driver write a Person reference into that variable, Java will fail in the same way.
Some of these bypasses are just lies, like “delete operator - Remove required properties”. You cannot delete a mandatory property from a type.
One thing I grant you that I was reminded of while reading that article is this: Some constructs are simply not expressible in TypeScript (that I know of). For instance, an object that serializes to valid JSON. That could be used to introduce type-unsafety (or whatever the correct term is).
From your second link:
TypeScript is indeed type-safe
Thanks for disproving yourself, I guess.
The medium article contains good examples, if a bit contrived. Thanks for digging that up.
Yes it is? It isn’t strictly sound, but it is type-safe aside from explicit escape hatches (which other type-safe languages also provide).
TypeScript’s type system exists only at compile time. When your code runs, it has been transpiled to plain JavaScript and all type information is erased, so TypeScript itself provides no runtime type safety.
Any runtime safety must be added explicitly (e.g., manual checks, schema validators like Zod, io-ts, or runtime assertions), but that safety does not come from TypeScript itself.
Sure, never claimed anything different. Runtime type safety != type safety.
Oh boy… now it’s what “kind” of type safety. The fake kind or the real kind. What other kinds of type safety is there?
Tell me you don’t know what type safety is after a 22 year career without telling me. Oh boy.
I love how you’re so angry that you follow me around. That’s the true meaning of being a loser 🥰 it took me a minute to remember who you were because I forgot about you hours ago. 🫡
I just saw your tag, “Vibe-coding schmuck”, in this post, and decided to give the same comment you gave me out of nowhere. 🤷♂️ Almost word for word mind you. Pretty scummy, right? (You should check the vote ratios in our comment threads btw.)
I like your delusions of grandeur that you think you have people following you around though. lol
Plays perfectly into the awful correspondence we had.
Yes, there exist different kinds of type safety. What the fuck are you even asking?
Haha name some more.
it’s just negligence with better marketing
Good damn I hate that tone it reeks of LinkedIn llm-powered personal branding. Weak ideas with writing that tries to sound strong is the worst.
Weak ideas with writing that tries to sound strong.
I move to make this the new definition of “Marketing”.
I guess I used to associate marketing speak with “let’s say something so bland nobody can really disagree with it” but this trend of writing platitudes like they are ground breaking expert insights is really grating to me
til: C++ is untyped.
Nonsense. If your code has reached the point of unmaintainable complexity, then blame the author, not the language.
I feel like there’s about one person that can cast this stone, and that’s because preventing this has turns Torvalds into an abusive bridge troll sometimes, but he’s actually been successful.
Well, the kernel is unmaintainably complex. Linux saves his sanity by not looking deeply into modules and only inspecting the surfaces.
