←back to thread

The C23 edition of Modern C

(gustedt.wordpress.com)
515 points bwidlar | 5 comments | 15 Oct 24 16:06 UTC | HN request time: 0.83s | source
Show context
survivedurcode ◴[16 Oct 24 05:02 UTC] No.41855777[source]▶
Continuing to use a memory-unsafe language that has no recourse for safety and is full of footguns and is frankly irresponsible for the software profession. God help us all.

By the way, the US government did the profession no favors by including C++ as a memory-unsafe language. It is possible to write memory-safe C++, safe array dereferencing C++. But it’s not obvious how to do it. Herb Sutter is working on it with CppFront. The point stands that C++ can be memory-safe code. If you make a mistake, you might write some unsafe code in C++. But you can fix that mistake and learn to avoid it.

When you write C, you are in the bad luck shitter. You have no choice. You will write memory—unsafe code and hope you don’t fuck it up. You will hope that a refactor of your code doesn’t fuck it up.

Ah, C, so simple! You, only you, are responsible for handling memory safely. Don’t fuck it up, cadet. (Don’t leave it all to computers like a C++ developer would.)

Put C in the bin, where it belongs.

replies(4): >>41855946 #>>41856045 #>>41856591 #>>41857805 #
purple-leafy ◴[16 Oct 24 05:38 UTC] No.41855946[source]▶
Skill issue
replies(1): >>41856860 #
pornel ◴[16 Oct 24 08:33 UTC] No.41856860[source]▶
It's been a skill issue for 40 years. How long are we going to continue searching for those programmers who don't make mistakes?
replies(1): >>41857317 #
1. worksonmine ◴[16 Oct 24 09:56 UTC] No.41857317[source]▶
Programmers make stupid mistakes in the safest languages too, even more so today when software is a career and not a hobby. What does it matter if the memory allocation is safe when the programmer exposes all user sessions to the internet because reading Dockers' documentation is too much work? Even Github did a variant of this with all their resources.
replies(1): >>41858204 #
2. pornel ◴[16 Oct 24 12:16 UTC] No.41858204[source]▶
Because memory vulnerabilities don't make programs immune to other dumb mistakes. You get these vulnerabilities on top of everything else that can go wrong in a program.

Manual checking of memory management correctness takes extra time and effort to review, debug, instrument, fuzz, etc. things that the compiler could be checking automatically and reliably. This misplaced effort wastes resources and takes focus away from dealing with all the other problems.

There's also a common line of thinking that that because working in C is hard, C programmers must be smarter and more diligent, so they wouldn't make dumb mistakes like the easy-language programmers do. I don't like such elitist view, but even if true, the better programmers can allocate their smarts to something more productive than expertise in programs corrupting themselves.

replies(2): >>41860345 #>>41957484 #
3. chongli ◴[16 Oct 24 15:38 UTC] No.41860345[source]▶
Because memory vulnerabilities don't make programs immune to other dumb mistakes. You get these vulnerabilities on top of everything else that can go wrong in a program.

The issue is that these great new tools don't just fix the old vulnerabilities, they also provide a lot of new, powerful footguns for people to play with. They're shipping 2000 feet of rope with every language when all we need is 6 feet to hang ourselves.

replies(1): >>41861038 #
4. pornel ◴[16 Oct 24 16:31 UTC] No.41861038{3}[source]▶
There has been a bunch of failed C killers, and C++ has massively shat the bed, so I understand that people are jaded.

However, this pessimistic tradeoff is just not true in case of Rust — it has been focused from the start on preventing footguns, and actually does a great job of it. You don't trade one kind of failure for another, you replace them with compilation errors, and they've even invested a lot of effort into making these errors clear and useful.

5. survivedurcode ◴[26 Oct 24 20:26 UTC] No.41957484[source]▶
> programmers can allocate their smarts to something more productive than expertise in programs corrupting themselves

Amen. This is called progress.