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.

  • pelya@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    7 hours ago

    JSON-in-a-string is a commonplace method of having a generic or any type when you are too lazy to write a proper structure for it, or want to save an object into a database without creating an additional table. In all fairness it has nothing to do with the language itself, and more with lazy coders. Postgresql even have additional SQL operators to access individual JSON fields inside a record, so yeah, you can dump a whole new unstructured database into a row of your existing database, it’s totally an acceped practice.

      • pelya@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        7 hours ago

        As for languages that are acceptable for business logic, C++ is lolno, Java is kinda surprisingly okay because so much business logic is already written in it and debugging is trivial, Python is not worse than Java for the same reason when you are using proper linter to catch typos, C# / Go / Ruby are probably the best because they are most modern with the lowest footgun ratio.