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

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

351–360 of 395 posts

Re: Modern C++ Won't Save Us

#351

Post by int_19h »

blub wrote: post #171
badsectoracula wrote: post #33

Earlier quoted context omitted.

C++ does have its positives, as you mentioned, but those positives do not make its negatives go away, nor having negatives means that there aren't positives. You can dislike some parts of the language while still using it for its positive aspect - that doesn't mean the negative parts do not exist nor mentioning them means that there are no positives.

Once again, this is not merely mentioning negatives, it's just more submarine advertising for Rust.

Rust is the only serious attempt to fix those negatives while remaining in the same niche, so bringing it up in this context is natural.

And C++ can't really truly fix them without breaking backwards compatibility with all the legacy C++ and C code, which is its main selling point.

Re: Modern C++ Won't Save Us

#352

Post by int_19h »

ncmncm wrote: post #128
Inityx wrote: post #74

Earlier quoted context omitted.

> the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary Looks to me more like proof that C++ has been around a long time

Lots of languages have been around a long time without attracting billions of lines of code. To get that, the language must be unusually useful.

I don't think anybody is denying that C++ was (and is) unusually useful, simply by virtue of being the only serious game in town when you need that whole "don't pay for what you don't use" thing, and general performance stemming from that. And devising a better replacement that retains that feature is hard, which is why C++ had so much time to entrench.

But it doesn't mean that we can't do it better these days.

Re: Modern C++ Won't Save Us

#353

Post by int_19h »

ncmncm wrote: post #332
_bxg1 wrote: post #136

Earlier quoted context omitted.

"or be seduced by C++'s greater expressive power" There's a deeper debate lying at the heart of the Rust-vs-C++ conversation (it's the same one at the heart of Haskell-vs-Lisp), which is really about expressive freedom vs. the strategic usage of constraints. That debate will, truly, outlive all of us. You can probably guess which side I'm biased towards; I won't lay it all out here.

This is not about "expressive freedom" vs "constraints". Rust lacks many of C++'s key core language facilities to capture semantics in a library. As a consequence, you cannot write powerful libraries in Rust that you can in C++, and you cannot use powerful libraries such as are written in C++. Since you cannot use these powerful libraries, you are (if you like) "constrained" to write fragile code at what would have b…

Can you give an example of said "key core language facilities" that make some library implementable in C++, but not Rust?

I can give an example of the opposite: language-aware macros. No amount of C++ TMP hackery can approach a well-designed Rust DSL.

Re: Modern C++ Won't Save Us

#354

Post by int_19h »

colanderman wrote: post #95
jandrewrogers wrote: post #71

A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more an…

What parts specifically? By my estimation, the only non-deprecated part of the standard library that really reeks of pre-C++11 (what I believe most consider the advent of "modern") is iostream. Most of e.g. the containers have been kept up to date with new features of the language (e.g. move semantics, constexpr). The standard library certainly is lacking things which are commonly used (say, JSON parsing or database…

Surely JSON does have a settled, obvious, lowest-common-denominator semantics?

Re: Modern C++ Won't Save Us

#355

Post by ncmncm »

lmm wrote: post #337
ncmncm wrote: post #333

Earlier quoted context omitted.

If I find a Rust program that is (perforce) not using powerful libraries, can I be confident that it does not harbor grave errors? Certainly not. Rust takes aim at memory errors, and misses the rest that would be avoided by encapsulating bug-prone code in libraries. C++ enables capturing bug-prone code in well-tested libraries, eliminating whole families of bugs, including, in my recent experience, memory bugs. That…

> If I find a Rust program that is (perforce) not using powerful libraries, can I be confident that it does not harbor grave errors? You can be confident that it doesn't harbour memory errors. You can be confident that it doesn't contain arbitrary code execution bugs, which is a much better circumstance than with any C++ project I've seen (C++ by its nature turns almost any bug into a security bug). IME you can also…

This is the classic False Dichotomy.

Rust programs have bugs. Rust programs have security bugs. Are they mediated by memory usage bugs? Probably not, unless the program has unsafe blocks, or uses libraries with unsafe blocks, or libraries that use libraries that have unsafe blocks, or call out to C libraries. Or tickle a compiler bug.

Can it leak my credentials to a network socket as a consequence of any of those bugs, memory or otherwise?

Putting your memory errors in unsafe blocks may make them invisible to you, but that does not make them go away.

So, yes, of course it can.

Re: Modern C++ Won't Save Us

#356

Post by blub »

int_19h wrote: post #351
blub wrote: post #171

Earlier quoted context omitted.

Once again, this is not merely mentioning negatives, it's just more submarine advertising for Rust.

Rust is the only serious attempt to fix those negatives while remaining in the same niche, so bringing it up in this context is natural. And C++ can't really truly fix them without breaking backwards compatibility with all the legacy C++ and C code, which is its main selling point.

It's the only "serious" attempt as declared by whom exactly, the committee of serious attempts?

There are other serious attempts (D, Swift, Go) which the Rust community likes to dismiss for various reasons, but at least two of them are currently much more successful than Rust. They don't have to be 100% in the same niche to take a bite of marketshare.

Even if C++ breaks backwards compatibility in some ways, it will still have better backwards compatibility to itself and C than Rust or any other language. This break could be something as radical as a C++ "unsafe", or it could be clang's -Wlifetimes, or something else. Credit's due to Rust here for pushing some parts of the C++ community to search for solutions.

Re: Modern C++ Won't Save Us

#357

Post by notacoward »

0xe2-0x9a-0x9b wrote: post #264

There is no call in the article for a deeper C++ code analysis by the compiler. Deeper analysis will be the future of C++ - the article fails to foresee this.

> Deeper analysis will be the future of C++

As if C++ compile times aren't crazy enough already.

Re: Modern C++ Won't Save Us

#358

Post by lmm »

ncmncm wrote: post #355
lmm wrote: post #337

Earlier quoted context omitted.

> If I find a Rust program that is (perforce) not using powerful libraries, can I be confident that it does not harbor grave errors? You can be confident that it doesn't harbour memory errors. You can be confident that it doesn't contain arbitrary code execution bugs, which is a much better circumstance than with any C++ project I've seen (C++ by its nature turns almost any bug into a security bug). IME you can also…

This is the classic False Dichotomy. Rust programs have bugs. Rust programs have security bugs. Are they mediated by memory usage bugs? Probably not, unless the program has unsafe blocks, or uses libraries with unsafe blocks, or libraries that use libraries that have unsafe blocks, or call out to C libraries. Or tickle a compiler bug. Can it leak my credentials to a network socket as a consequence of any of those bug…

> Can it leak my credentials to a network socket as a consequence of any of those bugs, memory or otherwise?

Sure, that class of bugs still exists. But they're rarer and less damaging (even with stolen credentials, an attacker can't do as much damage as one who had arbitrary code execution).

Rust eliminates many classes of bugs. C++ does not: the fact that theoretically there could be non-buggy C++ libraries doesn't help you out in practice, because there's no way to distinguish those libraries from the very many buggy C++ libraries.

> Putting your memory errors in unsafe blocks may make them invisible to you, but that does not make them go away.

It's just the opposite: it makes the risk very visible, so in Rust you can choose to avoid libraries with unsafe. Whereas in C++ any library you might choose is likely to have memory safety bugs and therefore arbitrary code execution vulnerabilities.

Re: Modern C++ Won't Save Us

#359

Post by majewsky »

eska wrote: post #302
jcelerier wrote: post #191

Earlier quoted context omitted.

> https://jaxenter.com/security-vulnerabilities-languages-1570... there's a world in terms of safety between C and C++.

You're misrepresenting the report in order to justify your bias. Direct quote from the report: This is not to say that C is less secure than the other languages. The high number of open source vulnerabilities in C can be explained by several factors. For starters, C has been in use for longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behi…

Readable version of the quote:

> This is not to say that C is less secure than the other languages. The high number of open source vulnerabilities in C can be explained by several factors. For starters, C has been in use for longer than any of the other languages we researched and has the highest volume of written code. It is also one of the languages behind major infrastructure like Open SSL and the Linux kernel. This winning combination of volume and centrality explains the high number of known open source vulnerabilities in C.

Please, never ever use code snippets for quotes, unless you hate mobile users. Just put "> " in front.

Re: Modern C++ Won't Save Us

#360

Post by majewsky »

ncmncm wrote: post #336
rcxdude wrote: post #299

Earlier quoted context omitted.

people who liked C (and didn't like C++) are more likely to move to go. Rust has a healthy community of ex and current C++ programmers.

People who don't like GC will not move to Go.

I don't like GC (on an ideological level), but I still write most stuff in Go because I'm so insanely productive in it. Will probably use more Rust once async/await is there and mature enough.
Post reply on HN