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.
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
Don't use any, and figure out any interfaces or types you don't have. Have a modocum of discipline to add the compile time safety
JavaScript introduces it, if it uses typescript code you lose all type safety
I add a lint rule to prevent using the
anytype. Solves the problemSo, not a language win after all?
Javascript is shit because it was never intended to be a serious language, but it's (realistically) the only language in browsers so it's everywhere. So there's necessarily a LOT of tooling to make it suck less. The current generation of tooling is starting to get kinda good, like Bun, Deno, Vite, Biome etc, but it's still a mess of competing standards, where other languages give you standards and simplicity for free.
I don’t understand how this would happen. If the any type truly “propagates through the system”, that means you’re passing around a variable of which you say, “I don’t know what this is. You deal with it.” How can you do any meaningful operations on it when you don’t know the type?
You write your typescript code to expect a given type but at the end of the day it's JavaScript with a type checking compiler so when "'any" gets in through a library or interface somewhere you just get a random "undefined" somewhere when you try to perform an operation with it because it's just JavaScript at the end of the day
What you’re describing is not really an ‘any’ type in the code but garbage data. No language is going to save you if you read a file expecting a character but it’s actually an int.
No the problem is that there's literally nothing at runtime stopping JavaScript inserting any type it wants into your function that only takes an int for example
Think of it like Haskell's
castfrom theTypeableclass.Yes, if somebody sends random stuff, you'll have to handle a failure, or do the equivalent of returning
undefined, what is way easier than properly handling it in TS. What you do from there is up to you.There are plenty of libraries to provide type safety at runtime.
Skill issue. You just didn't set up your tsconfig properly to begin with, which allowed someone to sneak in unsafe code.
I wouldn't make a typescript repo. But every single one I've had to work on has had the same problem