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.

  • carrylex@lemmy.world
    41·
    8 hours ago

    NPEs in Java usually have 2 causes and they are easily preventable:

    1. Parsing or deserializing data that must be present but is not. Fix: Add a validator or (introduced in Java 17 - 4 years ago) use records and do simple null validation there
    2. Devs coding weird shit that might or might not return null. Fix: Use annotations like NotNull/Nullable or the Optional wrapper (introduced in Java 8 - 11 years ago). There is also progress underway to be able to explicity declare type nullness, however - as always - Oracle invests more money into it’s lawyers instead of their devs, so it will take some time until this will be available.

    The problem is not really language specific because quite the same can also happen in any programming language, the symptoms/errors are just different.

    • expr@programming.dev
      1·
      3 hours ago

      Nulls are absolutely pervasive in Java and NPEs are not avoidable. At minimum, most of the ecosystem uses nulls, so most any library will have nulls as part of its interface. Null is an inhabitant of every type in Java (even Optional, ironically). You cannot escape it. It’s a fundamental flaw in the design of the language.

      Btw, you also can’t escape it in Typescript, either, due to unsoundness of the type system and the fact that many types for libraries are bolted on to the original JS implementation and may possibly be inaccurate. But still, it’s a lot less likely than Java.