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.
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.
Skill issue
- sincerely, someone making a DST crate
EDIT: To clarify...
There are some things that are only doable on nightly Rust (like specialization, const fn in traits, etc.) and the reason for that is to avoid future issues. In that regard, Rust will not be as good as C++... at least until those get stabilized.
Some of the nightly functionality (like
ptr_metadata) can be achieved withunsafecode and it's fine to do that, as long as it's only done when necessary and it's properly documented.It's okay to want to use C++, but that language has it's own issues and footguns (virtual destructors, "move semantics", C-style casts, header files and more) that Rust wants to avoid.
EDIT 2: Specialization is also kinda doable with deref coercion, but that's another can of worms I don't wanna open here.
EDIT 3: And if I had to mention some of Rust's footguns:
unwrappanics, which isn't bad in and of itself, but it's short so you'll probably want to use it instead of other error handling methods (see recent Cloudflare outages)unsafefunctions implicitly allows usingunsafeoperations (fixable by adding#! [deny(unsafe_op_in_unsafe_fn)])For my own Rust project I require myself to have a comment for every unwrap call that explains why that unwrap will never panic. For everything else I let the function return an error, with help of the anyhow crate and error contexts.