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.

top 50 comments

sorted by: hot top controversial new old

[–] pelya@lemmy.world 37 points 6 days ago (1 children)

TypeScript and safety-critical paths should not be in one sentence.

[–] mEEGal@lemmy.world 5 points 6 days ago (1 children)

wut ?

Why ?

Genuinely curious to learn from your arguments

[–] pelya@lemmy.world 28 points 6 days ago (1 children)

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.

[–] mEEGal@lemmy.world 2 points 2 days ago (1 children)

Okay I see your point

I personnally work in a servesless environment, and doubt many business applications really need parallelism. (Btw, you have to have at deast 1000 IQ to do it properly in C, C++ or Rust) Plus there are other TS runtimes now, so you don't have to use Node

As for strings as JSON, I don't understand the problem. You can do runtime validation to ensure what you're handling is of the right shape.

As for the numerous packages for the most basic thing, how is it different from C, C++ or Rust ? I prefer this approach to Java, where one framework does it all, bc there's innovation going on like crazy in the JS ecosystem and some established solutions feel like garbage now...

Personnally, I fell in love with TS because it's orders of magnitude better than plain JS and because the type system is very well designed. It's good enough for many usecases. Don't get me wrong, I'd love doing it in Rust on a daily basis, but my business needs rarely justify it

[–] pelya@lemmy.world 1 points 2 days ago (1 children)

JSON-in-a-string is a commonplace method of having a generic or any type when you are too lazy to write a proper structure for it, or want to save an object into a database without creating an additional table. In all fairness it has nothing to do with the language itself, and more with lazy coders. Postgresql even have additional SQL operators to access individual JSON fields inside a record, so yeah, you can dump a whole new unstructured database into a row of your existing database, it's totally an acceped practice.

[–] mEEGal@lemmy.world 1 points 2 days ago (1 children)

Oof, bad practice indeed.

Would NOT pass my code review

[–] pelya@lemmy.world 1 points 2 days ago

As for languages that are acceptable for business logic, C++ is lolno, Java is kinda surprisingly okay because so much business logic is already written in it and debugging is trivial, Python is not worse than Java for the same reason when you are using proper linter to catch typos, C# / Go / Ruby are probably the best because they are most modern with the lowest footgun ratio.

[–] echodot@feddit.uk 20 points 6 days ago (1 children)

So there is apparently a problem with languages such as JavaScript and the solution is to use languages such as TypeScript.

Wut?

[–] keegomatic@lemmy.world 12 points 5 days ago* (last edited 5 days ago) (7 children)

Well, yes. TypeScript mitigates one big problem with JavaScript (type safety). That’s why it exists. It’s a dumb idea to choose vanilla JS over TS if you’re starting a new project today, IMO.

Whether or not you should use TS as your core language is debatable and situational, but in terms of using TS instead of JS, yeah, that’s a no brainer.

load more comments (7 replies)

[–] sheepishly@fedia.io 22 points 6 days ago (2 children)

don't just m-dash

chat gippity

[–] chatokun@lemmy.dbzer0.com 18 points 6 days ago (2 children)

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.

load more comments (2 replies)

[–] Ashelyn@lemmy.blahaj.zone 10 points 6 days ago

Don't just state—regurgitate!

[–] wer2@lemmy.zip 11 points 6 days ago (2 children)

Sounds like they want Ada Spark and not Rust.

[–] baines@lemmy.cafe 2 points 6 days ago

i laughed pretty hard thinking isn’t that just ada

so we got rid of ada for c++ now from c++ to rust chasing ada lmao

load more comments (1 replies)

load more comments