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.

  • FooBarrington@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    20 hours ago

    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).

    • velindora@lemmy.cafe
      link
      fedilink
      English
      arrow-up
      0
      ·
      12 hours 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.

        • velindora@lemmy.cafe
          link
          fedilink
          English
          arrow-up
          0
          ·
          11 hours ago

          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?

          • Victor@lemmy.world
            link
            fedilink
            arrow-up
            0
            ·
            5 hours ago

            Tell me you don’t know what type safety is after a 22 year career without telling me. Oh boy.

            • velindora@lemmy.cafe
              link
              fedilink
              English
              arrow-up
              0
              ·
              5 hours ago

              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. 🫡

              • Victor@lemmy.world
                link
                fedilink
                arrow-up
                0
                ·
                5 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.