this post was submitted on 28 Dec 2025
266 points (94.6% liked)

Programmer Humor

28058 readers
1022 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] affenlehrer@feddit.org 18 points 12 hours ago (1 children)

In my 15+ years of experience many of the actual field problems are not language / programming related at all. Unclear requirements or clear but stupid requirements cause loads of issues. These are often caused by communication problems between people and / or organizational issues.

It depends a lot on the industry of course. For embedded software, low level networking etc I mostly agree with you. However, in business applications or desktop applications it's from my experience mostly bad requirements / communication.

[–] pivot_root@lemmy.world 11 points 11 hours ago

Don't forget to add incompetent leadership to that list. If feature needs to be shipped by some arbitrary deadline and the engineers are forced to rush through the design process, you end up with a patchwork hack of tech debt that leads to more tech debt.