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

131–140 of 395 posts

Re: Modern C++ Won't Save Us

#131

Post by usrnm »

mempko wrote: post #118
nradov wrote: post #108

Earlier quoted context omitted.

Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?

C++ is designed for people to make nice libraries. Unlike other languages there is nothing special about the standard library (no magic language hacks). All libraries are first class citizens by design.

Good luck implementing something like std::is_standard_layout without "magic language hacks". No, not all libraries are made equal and std is part of the language now, there is no way back

Re: Modern C++ Won't Save Us

#132

Post by jclay »

_bxg1 wrote: post #75
jclay wrote: post #14

I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…

But most of the things you just listed are just aspects of the existing ecosystem (libraries, tooling, etc.). There's no doubt C++ has an incredibly large ecosystem and will therefore be around for quite a while to come, but that doesn't make it a good language , it just makes it one that happens to have been very popular for a very long time. Our industry is one that values progress over tradition in the long run. I…

The point is that I've noticed a broad "religious" trend where those promoting Rust don't lend any credit to the places where C/C++ has valid strengths, even if due to it's legacy. It doesn't do a great service to either community to constantly pit the two against each other, and to misrepresent the other in a way that's not honest. C++ doesn't exist and continue to evolve just because it's been around forever, there are a number of things leading to it's continued use that should be brought into the discussions.

C++ isn't going anywhere. In 20 years you may not be writing in it, but you'll still be calling into it somewhere in the software stack (especially if things continue moving the WebAssembly direction).

Even if you're using Python's SciPy today, you're calling into LAPACK written into Fortran.

Re: Modern C++ Won't Save Us

#133

Post by ncmncm »

magila wrote: post #53
jclay wrote: post #14

I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…

While there are obviously still cases where C++ makes sense to use today, those case are overwhelmingly based on the age and maturity of the C++ ecosystem. Now that Rust has proven that a language can provide memory safety without compromising (much) on performance, it is clear that the scope of C++'s supremacy is in permanent decline. As Rust (or another language with similar safety/performance properties) matures a…

If C++ is the new Fortran, Rust might very well be the new Ada. Many of the same relative merits were claimed for Ada as for Rust, and it had the backing of the biggest and best-funded organization in the world, but it faded from view because it did not keep up.

Rust could easily go the same way.

Re: Modern C++ Won't Save Us

#134

Post by paulmooreparks »

Tracist wrote: post #116
ncmncm wrote: post #114

Earlier quoted context omitted.

There is no such language as C/C++. There is C, which cannot be written safely, and there is C++, which can be, and quite often is. It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. I am constantly dealing with design, specification, and logic flaws, which affect Rust equally, or moreso. I am aware that there are plenty of other programmers out there, writing bad code in…

> It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. The whole comment sounds so much like well written satire, but I think he's being serious.

Why is it difficult to believe? I've also written plenty of C++ code without memory bugs. It's not that hard if you play by a few simple rules.

Re: Modern C++ Won't Save Us

#135

Post by alfalfasprout »

tatersolid wrote: post #41
namirez wrote: post #7

This has been discussed extensively in the C++ community. I think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. These are added to the language to prevent memory allocation and data copy for performance critical software. Herb Sutter has concrete proposals to address this issue and Clang already supports them: https://www.infoworld.com/artic…

> think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. That’s the whole point: your caveat shows that’s it’s C/C++ which are unsafe in their very nature and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful. HPC are generally closed systems and have differ…

"which is just about everything useful". This statement is wildly without merit.

Sure, for the typical user facing application HN readers talk about then C++ can certainly contain vulnerabilities that are worrisome. Many performance critical applications can tolerate vulnerabilities in favor of latency.

It seems to me that the world of realtime systems including avionics, autonomous control software, trading, machine learning, and more is "not useful" as per your comment. The extreme low level control that C++ offers and powerful metaprogramming allows for performance that even Rust cannot hope to rival.

The industry has moved away from C++ for plenty of these user facing use cases. Codebases like Chrome and Firefox can't just be rewritten in Rust overnight. You can try and rewrite eg; SSL libraries but that has its own host of problems (eg; guaranteeing constant time operations).

I encourage the people parroting a move away from C++ to really think about what it is that should move and what the pros/cons are. I think you'll find that many of the things at risk (i.e user facing applications) are already on their way to being rewritten in Go/Rust.

Re: Modern C++ Won't Save Us

#136

Post by _bxg1 »

ncmncm wrote: post #117
_bxg1 wrote: post #75

Earlier quoted context omitted.

But most of the things you just listed are just aspects of the existing ecosystem (libraries, tooling, etc.). There's no doubt C++ has an incredibly large ecosystem and will therefore be around for quite a while to come, but that doesn't make it a good language , it just makes it one that happens to have been very popular for a very long time. Our industry is one that values progress over tradition in the long run. I…

That doesn't make C++ a good language. It just is one. Rust is also a good language. Trash-talking C++ does no one any good. Overwhelmingly, the substantial gains to be made are moving people off of C. Every other possible benefit is a rounding error. It is still much easier to get people to C++. Once dislodged, they might continue on to Rust, or br seduced by C++'s greater expressive power and more powerful librarie…

"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.

Re: Modern C++ Won't Save Us

#137

Post by ncmncm »

hermitdev wrote: post #73
MiroF wrote: post #54

Earlier quoted context omitted.

UB isn't "safe" so I'm unsure what your comment is getting at

I guess the point I was trying to make is that what is referred to colloquially as dereferencing is different than how the compiler sees it. We see " foo" (can't get HN to emit the asterisk for pointer dereference here, no matter what I try ), and we know that to be UB, but the compiler doesnt really see it until the load. Until its actually used, its effectively a dead store and will be eliminated, anyway. int& bar…

This is very definitely false. That is totally UB, launch-the-missiles stuff. Check your references before you repeat this silliness.

Re: Modern C++ Won't Save Us

#138

Post by kllrnohj »

fooker wrote: post #101
Animats wrote: post #93

The C++ people are trying to refit ownership to the language without adding a borrow checker. This is painful. They've made it possible to write code that expresses ownership, but they can't catch all the places where the abstraction leaks. string_view is really a non-mutable borrow. But the compiler does not know this.

> but they can't catch all the places where the abstraction leaks. Why does static analysis not work here?

It does, it's just a warning and not an error. And also experimental.

But it does exist, and does catch some of these errors. Example: https://godbolt.org/z/CZTfSx

Re: Modern C++ Won't Save Us

#139

Post by ncmncm »

swiftcoder wrote: post #50
the_trapper wrote: post #46

Earlier quoted context omitted.

Rust's learning curve isn't exactly a shallow one either. For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.

It's a bona fide C++ killer for applications that are both security and performance critical. It's already gaining traction for those applications even within relatively conservative engineering organisations. That said, there are many performance-critical applications who are not security-critical, and in those I'd expect C/C++ to persist pretty much indefinitely. And many security-critical applications which are no…

It is a legitimate C killer. C++, not so much.
Post reply on HN