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.
lol. Typescript isn’t actually type safe.
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.
Your raw rage is making my day thanks bud.
Yes, there exist different kinds of type safety. What the fuck are you even asking?
Haha name some more.
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.