Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ creator rebuts White House warning

infoworld.com

Post reply on HN
Print view View original

101–110 of 141 posts

Re: C++ creator rebuts White House warning

#101

Post by kazinator »

nradov wrote: post #66
marcus0x62 wrote: post #10

> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. I and the C++ standard committee are trying to deal with that If only people were perfect, then things would be perfect. There’s, what, 40 years of evidence to suggest that most people, most of the time, simply cannot write memory-safe C++ code (50 years if you count C.) Ma…

Have we tried genetically engineering perfect C++ programmers? I feel like that might be possible in another 50 years.

If they don't have to be human, probably 10-15.

Re: C++ creator rebuts White House warning

#102

Post by arcticbull »

froh wrote: post #98
arcticbull wrote: post #3

> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. The fundamental problem is they’re just guidelines and they’ll always be just guidelines. You can still do all the wild old stuff without so much as a warning and you’ll have to figure out how it even interacts with the new stuff which exposes yet another vector for failure…

linters nudge about not following guidelines, and project policies turn the Judges into enforcement.

Which is fine until you have third party dependencies.

Re: C++ creator rebuts White House warning

#103

Post by germandiago »

kstrauser wrote: post #7

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…

On the other side, Rust is a safe language that in real world uses unsafe blocks and unsafe libraries underneath (OpenSSL and other C libraries in practical terms).

That is not safe either in practical terms.

So there is always this discussion about putting C++ as an unsafe thing and it depens a lot, as you said, on how you use it.

I use max warning level, warnings as errors, smart pointers, almost everything return by value and sanitizers.

In Rust I have the advantage that libraries can be audited for unsafe blocks, but it still has unsafe and it will still use unsafe libraries in practice from C.

So I always challenge these people that say Rust is safe. It is when it is. In rea life it is not perfect.

I am pretty sure that the distance gap in safety from well-written C++ and Rust is, well, very small.

Re: C++ creator rebuts White House warning

#104

Post by eclectic29 »

lostmsu wrote: post #91
eclectic29 wrote: post #46

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.

The reason for that mostly is CUDA only supports C and C++ natively.

Try writing high performance math in Java even for CPU.

Re: C++ creator rebuts White House warning

#105

Post by User3456335 »

lostmsu wrote: post #93
User3456335 wrote: post #70

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…

Don't use Python. You will produce unmaintainable code that will have to be thrown away in 5 years because it is impossible to refactor.

Interesting. Are you sure it's the language and not the programming style? There doesn't seem to be a reason to prevent you from writing maintainable Python code.

Re: C++ creator rebuts White House warning

#106

Post by tialaramex »

User3456335 wrote: post #70
klodolph wrote: post #23

Earlier quoted context omitted.

> The first step to solving a problem is accepting reality. Ok, the first thing I’d like to accept is that C++ is just not safe enough for most applications. And yes—you also can’t throw C++ in the garbage. Both of those statement are part of our reality—C++ is unsafe, and we will use it anyway. That’s why we solve this problem on two fronts. First, we advise programmers to ditch C++ for safer languages, when reasona…

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…

> "Look, I have a map of the minefield".

This doesn't exist. WG21 (the C++ language committee) has considered the idea of writing an appendix with such a map - a list of the UB (Undefined Behaviour) and IFNDR (Ill-formed, No Diagnostic Required) clauses in the language but this work has yet to be undertaken and I see no reason to expect it in C++ 26.

I have been in plenty of disagreements with C++ proponents here and on r/cpp where it's clear that there isn't even agreement on what the standard means today in respect of these problems, if you guess one way and the people who implemented your compiler judged differently then your program may have defects you didn't even realise were possible.

Re: C++ creator rebuts White House warning

#107

Post by marcus0x62 »

cbsmith wrote: post #82
marcus0x62 wrote: post #55

Earlier quoted context omitted.

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 argumen…

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

It seems to me to be directly related when modern languages make certain types of mistake impossible, imperfect though the creators of those languages are.

> That's an entirely different argument, and depends on the semantics of "unsafe" and "foot guns".

No. It is literally the same argument. People are imperfect, and will make mistakes (that are possible to make.) In the case of C++, we have decades of evidence that people will make memory-safety mistakes over and over and over again.

Re: C++ creator rebuts White House warning

#108

Post by edflsafoiewq »

germandiago wrote: post #103
kstrauser wrote: post #7

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…

On the other side, Rust is a safe language that in real world uses unsafe blocks and unsafe libraries underneath (OpenSSL and other C libraries in practical terms). That is not safe either in practical terms. So there is always this discussion about putting C++ as an unsafe thing and it depens a lot, as you said, on how you use it. I use max warning level, warnings as errors, smart pointers, almost everything return…

Certainly it is a question of degrees.

But to say the gap in safety is very small is essentially to say Rust's lifetime system is close to zero-value.

Unsafe code still exists, the goal is to localize it to small, auditable blocks. However safety often depends on non-local properties. For example, unchecked iteration over a vector requires we know the vector's lifetime exceeds the iteration lifetime, and that the backing buffer won't change. Rust's lifetime system allows this to be expressed, so the "critical zone" can be localized within a single block in the library implementation. If the library is correct, all consumers are safe. In C++, these cannot be expressed, so the critical zone for this safety guarantee is smeared across all code executed during the iteration. No consumer is guaranteed safe.

Re: C++ creator rebuts White House warning

#109

Post by jvanderbot »

User3456335 wrote: post #70
klodolph wrote: post #23

Earlier quoted context omitted.

> The first step to solving a problem is accepting reality. Ok, the first thing I’d like to accept is that C++ is just not safe enough for most applications. And yes—you also can’t throw C++ in the garbage. Both of those statement are part of our reality—C++ is unsafe, and we will use it anyway. That’s why we solve this problem on two fronts. First, we advise programmers to ditch C++ for safer languages, when reasona…

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…

isolated experiments and a rank-choice ordering of languages is not a realistic picture of the industry.

In robotics, everything is C++. There's plenty of python being used to train networks, but that's not because of performance, safety, or anything, it's mostly born out of the existence of key libraries being in Py. But those libs are just wrappers on C (cuda, essentially).

Essentially the whole of every robot is C and C++. Essentially the whole of every airplane is C, C++, and a scattering of memory safe languages in isolated corners. The ATC system, the rail system, most industrial processes are C or PLC, or maybe C / PLC generated by matlab/labview. Automobiles, basically everything with a microcontroller. It's all C.

Our scientific computing? fortran. Nodejs? A bunch of C++.

What's my point? It's that for any new project or extension of above projects, the existing language is a superior choice (as viewed by managers, business leaders, CTOs, or rushed grad students trying to get quick results, etc), simply because the legacy provides a quicker startup. This is the "reality" - we have had better options essentially forever, and I feel we are effectively stuck with C/C++ forever. It's just that we'll see less and less of it if the new communities are diligent about extending the existing ones. Otherwise, it will never make sense to start clean, not on a mass production level, or at least not this decade or likely next.

C++ is a bad choice, and it is the choice. it can be both a prevalent "obvious" choice, and also a bad one. The existence of a better language does not shift reality on its own. You need targeted investment for development of a replacement ecosystem built around that better option. Whether that is Rust, or safe C++, or C+borrow checking, or Dada, or the language of the minute. We as a community cannot keep screaming about how nice a new idea is without building out the ecosystem to make it the obvious idea.

Re: C++ creator rebuts White House warning

#110

Post by marcus0x62 »

Calavar wrote: post #48
kstrauser wrote: post #7

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…

I'd say it's actually the other way around. C++ in the abstract is full of half-baked, ill conceived ideas that later had to be deprecated or walked back entirely: std::auto_ptr and memory leaks; std::shared_ptr::unique() not being threadsafe; taking the time to implement bounds checking in std::vector, but the default access operator isn't checked; corner cases with std::initializer_list leading to unexpected behavi…

> Crates.io feels like a graveyard of experimental libraries that reached 40% the functionality of their C++ cousins before the commit activity dropped to zero.

Not only that, but you see a huge increase in external dependencies because of the ease of importing crates. I'll admit I have absolutely no evidence to back this up, but the crates system feels to me like the Achille's Heel of Rust's security model in two respects:

1) There's the obvious supply-chain risk in that the provenance of most of these crates is...uncertain at best... At best you can see some stats that x number of projects use the crate, and who the owner is or at least purports to be.

2) Having eliminated most memory-related vulnerabilities (or at least constrained them to unsafe blocks,) the remaining vulns are going to tend to be logic flaws, and Rust, of course makes no guarantees in that realm. If you import 1 crate, ok, you can probably audit that crate and maybe reason accurately about what your code is really doing. But, when you import a half dozen crates, and those crates have dependencies, and so on, and you end up with 100+ external dependencies, I would argue that reasoning accurately about the behavior of your code is going to be quite difficult.

To me, this is a cultural problem/blindspot with Rust that will be difficult to fix.

Post reply on HN