Live data from Hacker News

C++ creator rebuts White House warning

infoworld.com

81–90 of 141 posts

Re: C++ creator rebuts White House warning

#81
post #28

Even such basics as initialization is full of traps in C++, its truly language thats awful to produce anything safe with. C on the other hand isnt a bad language, but C's problem comes from the horrible standard library and bad standard. You can create much better C by passing -fno-strict-aliasing -ftrapv -fsigned-char to the compiler even now. Heck rust's unsafe is more unsafe than C. "C" could be improved with a be…

>> "C" could be improved with a better compiler that ignores the standard, but perhaps it wouldnt be C anymore

Then it wouldn't be C.

C is 52 years old. For most use cases, there are better options.

Instead of trying to apply bandages to C or C++, why not move to something better?

Legacy code written in C or C++ can be maintained or rewritten as needed. New code should not be written in C or C++ because it is not safe--thus the White House warning.

Re: C++ creator rebuts White House warning

#82
post #27

Earlier quoted context omitted.

> If only people were perfect, then things would be perfect. That argument doesn't hold up too well, considering that people are involved either way.

It’s been holding up pretty well for the specific memory safety guarantees offered by modern languages, and for a simple reason: if your language is unsafe and has a bunch of foot guns in it, all the users of that language have to be perfect all the time to avoid trouble. If your language provides a certain safety guarantee, the implementors of that guarantee have to be perfect, but at least you have a relatively con…

> It’s been holding up pretty well for the specific memory safety guarantees offered by modern languages

That seems unrelated to whether people need to be perfect to avoid security exposures. In fact, it would seem to be in contradiction.

> if your language is unsafe and has a bunch of foot guns in it, all the users of that language have to be perfect all the time to avoid trouble

That's an entirely different argument, and depends on the semantics of "unsafe" and "foot guns". I think it's more than fair to say that having more protections in place allows for mistakes to avoid becoming vulnerabilities more often, but that's a different argument.

Re: C++ creator rebuts White House warning

#83

There's the language as idealized, and the language as used. Stroustrup is clearly brilliant, but he's talking about the former while everyone else means the latter. If you started a brand new C++ project today, using only the modern, safe ways of doing things and including only dependencies that do the same, OK, fine. That's, what, 0.1% of C++ projects? The rest of them use a soup of features and misfeatures that've…

> With enough discipline and tooling, it is possible to write safe C++ I think it's possible to write "safe enough" C++ for real-world use. Then after some time you get a weird crash because MSVC stdlib implementation does something weird in new spec. Or your dependency does something unsafe and hoses you. Or the new guy uses `std::string_view` but forgot it doesn't guarantee null-termination. Or you casually forget…

string_view doesn't guarantee life time of the backing buffer either. It's a fundamentally memory unsafe type.

Re: C++ creator rebuts White House warning

#84
post #28

Even such basics as initialization is full of traps in C++, its truly language thats awful to produce anything safe with. C on the other hand isnt a bad language, but C's problem comes from the horrible standard library and bad standard. You can create much better C by passing -fno-strict-aliasing -ftrapv -fsigned-char to the compiler even now. Heck rust's unsafe is more unsafe than C. "C" could be improved with a be…

>> "C" could be improved with a better compiler that ignores the standard, but perhaps it wouldnt be C anymore Then it wouldn't be C. C is 52 years old. For most use cases, there are better options. Instead of trying to apply bandages to C or C++, why not move to something better? Legacy code written in C or C++ can be maintained or rewritten as needed. New code should not be written in C or C++ because it is not saf…

I've already moved to zig since it's the only real C alternative out there right now. I'm just making a point C itself as a written language is not bad. You could make something that is very similar, but avoids most of the common issues with C (which are much less than with C++). C won't die and interop will be the C ABI for long time still.

Re: C++ creator rebuts White House warning

#85

Earlier quoted context omitted.

I've yet to see a valid scenario where C++ is superior to Rust, Python and Go. Use Python. If you need concurrency, then use Go. If you need even more performance, use Rust (using unsafe Rust only for the parts that need it). For the highest performance stuff, maybe consider C for critical parts only. C++ is not safe. It's a minefield of things that compile but are memory management mistakes. And then you're like "Lo…

I can think of a few scenarios for C++ off-hand. Most of them involve integrating with libraries or frameworks that are written in C++, running on platforms that have good C++ toolchains, or working with verification systems that can process certain C++ or C subsets.

Yes, but all of these are essentially all because the existing code is already based on C(++). We should be able to move to Rust sooner than people think.

Re: C++ creator rebuts White House warning

#86
post #56

Earlier quoted context omitted.

70% sounds a bit high but I can accept it. You can do a lot in regards to memory safety also in C / C++ : https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf Anyway. Writing safe code in C is HARD but possible. Especially with good tooling. That is not to say everyone should use C. C is an exceptionally hard language to use safely and correctly and is not for everyone.

> 70% sounds a bit high but I can accept it One meta-source for this is Prossimo[0]. They link to multiple vendor reports that range from 60 - 90%. > Writing safe code in C is HARD but possible. Especially with good tooling. I don’t disagree in theory, but I think it is so hard as to be impractical in almost every case. So, other than maintaining a legacy code base, why try at this point when other options are availa…

> So, other than maintaining a legacy code base, why try at this point when other options are available?

What options would you recommend in 2024? I write C (not C++) and work on projects that are inherently memory unsafe (the last one required hand-written assembly code). I've explored potential C successors in the past, but have yet to discover one that matches the freedoms, simplicity, ergonomics, and performance of the C language.

Re: C++ creator rebuts White House warning

#87
post #68

Earlier quoted context omitted.

I acknowledge C++'s safety concerns, but no, Java is definitely NOT running rings around C++ perf. Not a single AI/ML model is implemented in Java. The core of AI/ML runs on C++ only. You may see a lot of Python, but the core engine that Python is wrapping is written in C++. Sorry to break it to you but Java cannot even come close here.

"Multiply an insane amount of stuff" is not an interesting point in complexity-safety-performance space.

> "Multiply an insane amount of stuff" is not an interesting point in complexity-safety-performance space.

So in other words, Java is bad at scaling a basic math operation like multiplication?

> "In many ways Java is running rings around C++ performance"

The AI-space is proof positive of that being false. C++ is kicking Java's butt, squeezing literally trillions of ops per second of performance, all of this happening before the Java runtime can even startup.

The first transformer-based language model was built with PyTorth; imagine if PyTorch was a python wrapper for Java code instead of C++ code? It'd be garbage. I mean how freaking long did it take for Java to even get a basic Vector API? C++ devs have been writing SIMD optimized code for years now. And besides that, try getting a Java program to scale at tens or even hundreds or thousands of GPUs for a large language model. You'd need GPUs with literally 20-30% more RAM just to accommodate the GC.

Re: C++ creator rebuts White House warning

#88

Earlier quoted context omitted.

I can think of a few scenarios for C++ off-hand. Most of them involve integrating with libraries or frameworks that are written in C++, running on platforms that have good C++ toolchains, or working with verification systems that can process certain C++ or C subsets.

Yes, but all of these are essentially all because the existing code is already based on C(++). We should be able to move to Rust sooner than people think.

Should ≠ will.

We still have Fortran and Cobol. It’s easy to imagine that Rust will replace C++ Real Soon Now, because you just have to imagine that all of the legacy code disappears, and Rust gets all the tooling support that C++ has.

Re: C++ creator rebuts White House warning

#89
post #86

Earlier quoted context omitted.

> 70% sounds a bit high but I can accept it One meta-source for this is Prossimo[0]. They link to multiple vendor reports that range from 60 - 90%. > Writing safe code in C is HARD but possible. Especially with good tooling. I don’t disagree in theory, but I think it is so hard as to be impractical in almost every case. So, other than maintaining a legacy code base, why try at this point when other options are availa…

> So, other than maintaining a legacy code base, why try at this point when other options are available? What options would you recommend in 2024? I write C (not C++) and work on projects that are inherently memory unsafe (the last one required hand-written assembly code). I've explored potential C successors in the past, but have yet to discover one that matches the freedoms, simplicity, ergonomics, and performance…

Zig. It's not as safe as Rust, but it's a hell of a lot better than C while remaining largely interoperable.

Re: C++ creator rebuts White House warning

#90

Earlier quoted context omitted.

I don't like Java. Nothing about it appeals to me. It pains my eyes to look at it. And in spite of my distaste for it, I respect that it completely eliminates giant classes of vulnerabilities. You can write bad logic in any language. At least in Java you can't write bad logic that also suffers from memory issues.

> At least in Java you can't write bad logic that also suffers from memory issues. Oh you bet you can. There are a number of ways to screw that up. - memory leaks/loitering is quite common, gc won’t help if your code hangs on to stale refs - using Unsafe memory can blow up in glorious C++ fashion, directly or indirectly - using native calls incorrectly can be just as nasty

I'd wager Unsafe in Java is far more rare per million lines of code written than unsafe blocks in Rust. Been coding in Java since ~1997. Unsafe just doesn't come up in 99.999% of Java projects.

Now JNI on the other hand, that made up maybe 0.5% back in the day. Not anymore where FFI is the predominant native linkage (but still comparatively quite rare).

(Cue the one weird guy coming out of the woodwork who claims that all of his Java projects in the last 10 years have used Unsafe to great effect.)

Post reply on HN