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?
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.
Keep being delusional, Mr. Replaceable. 👋
Go get comforted by your loving wife and kids who I’m sure really respect you.
Aww thanks, first nice thing you said all day. Hope it didn't burn your skin.
I’ve never been upset. Just amused. I wish the best for you in the upcoming years. 💋
Hard to believe those words considering your previous words, there, bud.
Yes, there exist different kinds of type safety. What the fuck are you even asking?
Haha name some more.
Explain or be downvoted
https://ltscommerce.dev/articles/typescript-honesty-system.html
https://www.xjavascript.com/blog/is-typescript-type-safe/
https://medium.com/@veenixdev/typescript-and-the-illusion-of-type-safety-72de07417324
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:
Thanks for disproving yourself, I guess.
The medium article contains good examples, if a bit contrived. Thanks for digging that up.
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.