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.

(page 3) 50 comments

sorted by: hot top controversial new old

[–] ryannathans@aussie.zone 8 points 1 day ago* (last edited 1 day ago) (12 children)

Typescript literally doesn't work though, every large system has some JavaScript interface somewhere and the "any" type propagates through the system because there's no type safety at runtime

Fuck them both to death

[–] danhab99@programming.dev 7 points 1 day ago (2 children)

I add a lint rule to prevent using the any type. Solves the problem

load more comments (2 replies)

[–] FooBarrington@lemmy.world 3 points 1 day ago

There are plenty of libraries to provide type safety at runtime.

load more comments (10 replies)

[–] velindora@lemmy.cafe 3 points 1 day ago (16 children)

lol. Typescript isn’t actually type safe.

[–] bleistift2@sopuli.xyz -3 points 1 day ago (3 children)

Explain or be downvoted

[–] velindora@lemmy.cafe 1 points 1 day ago

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.

load more comments (2 replies)

load more comments (15 replies)

[–] aaaaaaaaargh@feddit.org 2 points 1 day ago* (last edited 1 day ago)

Edit: removed because I got it wrong

[–] thericofactor@sh.itjust.works 1 points 1 day ago (1 children)

I've written thousands of lines of untyped python code for a system (still) used daily by hundreds of users, handling time critical as well as financial data. It made the company I worked for millions and it worked. Was it bug free? Nope, bugs would appear in production from time to time, but they were very easy to detect, and very quickly solved, especially because of the fact that python is an interpreted language. In 7 years of working on that application there was only one bug that caused data corruption and required us to reprocess some data that took a day or three. That was the worst thing to happen in the entire lifetime of that codebase. I totally agree that if you structure your code properly, log properly and give your developers the trust and permissions to actually solve stuff in production quickly, you might even get a competitive advantage.

[–] bleistift2@sopuli.xyz 3 points 1 day ago

I wish people downvoting literal case studies would at least give a reason…

[–] termaxima@slrpnk.net 0 points 1 day ago

You can absolutely blame the language in the case of C++ !

Also, the author ? Many large scale projects are a mish-mash of dozens or hundreds of authors. If the language doesn't facilitate teamwork, and they don't have a Linus to oversee it all, things can quickly degenerate to the point of incomprehensibility, through the fault of no single person in particular.

load more comments