401

submitted 3 days ago by danhab99@programming.dev to c/programmer_humor@programming.dev

175 comments fedilink hide all child comments

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.

(page 2) 50 comments

sorted by: hot top controversial new old

[-] thedeadwalking4242@lemmy.world 9 points 3 days ago

I half way agree. I always say form shapes function. Sure you can write good code in any language. But some encourage it more then others. Ultimately it's the programmer fault when things get over complex though

[-] douglasg14b@lemmy.world 4 points 2 days ago* (last edited 2 days ago)

Honestly, I more than half agree because the factor most seem to conveniently ignore is that languages and environments that encourage better and safer code are aimed at the lowest common denominator.

The lowest common denominator of developers are the ones that benefit the most from a reduction in defects or unsafe code they may produce. They are the biggest pool of developers. And in my experience, the ones least likely to proactively take measures to reduce defect rates unless it's forced upon them and/or baked into their environment.

They are the ones that will slap any in typescript to resolve errors instead of actually resolving them, or the ones that will use dynamic in C# instead of actually fixing the bad design ... etc

[-] hddsx@lemmy.ca 15 points 3 days ago

Dunno, I picked python as my language for personal projects because it has type hinting now and jobs I was looking at wanted it. I’d like to use C# but I need to find a good IDE on Linux.

I’ve gotten pretty good at C because it’s what my company uses but god damn I am tired of fixing memory errors from bad programming. Nobody uses best practices and it’s horrid. Best practices came about to avoid issues. Use them. Please. I don’t want to be the guy to answer “please fix my memory issues” tasks. If you don’t know what you’re doing, please choose a different god damn language.

I’ve only gotten this way because I’ve tried to read the fucking manual. Stop telling me I’m wrong when you don’t know how it works. Stop telling me I’m wrong when you don’t check for errors. I’m telling you this not because I want to talk. I’m telling you because I learned the hard way fixing your code and I don’t want to do it anymore.

load more comments (12 replies)

[-] curled@lemmy.dbzer0.com 10 points 3 days ago

Embedded devs have heavy gambling addiction apparently