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

21–30 of 395 posts

Re: Modern C++ Won't Save Us

#21

Post by 932 »

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…

Yeah, agreed. The points in the article are valid, but quirks you learn and get past the first time. I still shoot myself in the foot sometimes even though I don't have a single bare new/malloc without a shared/unique ptr! But that's C++ for you.

But, C/C++ is the best option for us for high-performance network processing. We're dabbling with Rust for small applications where we would use Python previously and it's working pretty well -- but there's no way we could use Rust for the core application yet. Modern C++ has really grown on me and it's sometimes a love/hate relationship but totally a huge improvement over ancient C++ or C.

Re: Modern C++ Won't Save Us

#22

Post by blihp »

jmole wrote: post #15

Question - How does one write microcontroller code (or other memory-mapped I/O code) using a memory-safe language?

Historically speaking, you didn't. It is only relatively recently that microcontrollers have become powerful and spacious enough for that to be an option.

Re: Modern C++ Won't Save Us

#23

Post by wwright »

the_trapper wrote: post #16
wwright wrote: post #13

Earlier quoted context omitted.

The thing is, Rust has tools that are easier to use _and_ have great performance _and_ prevent security and stability mistakes.

However Rust is single vendor and single implementation, has a much smaller community and ecosystem than C++, is not standardized, and does not support all of the platforms and use cases that C++ does.

That’s very true. But all of those communities, ecosystems, standards, and use cases have an extreme learning curve and a very deep problem with security. :-)

Re: Modern C++ Won't Save Us

#24

Post by 0815test »

leshow wrote: post #12

Rust and Swift have different definitions of memory safety, don't they?

Yes, AIUI Swift does not ensure memory safety for concurrent code like Rust does. You have to expressly opt-in to concurrency-safety, and it's not checked by the compiler. Go definitely has this issue, which is admittedly bizarre for a language that's so often used to code network-oriented services making heavy use of concurrency.

Re: Modern C++ Won't Save Us

#25

Post by mannykannot »

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…

std::auto_ptr was fixed one or two times before being replaced. It is a little bit unsettling to see newer features having the same sort of caveats, despite there being a lot of smart people planning the future of the language. I imagine this is due to the way that the existing features combine combinatorially to multiply the complexity of every new feature.

Re: Modern C++ Won't Save Us

#26

Post by phkahler »

the_trapper wrote: post #16
wwright wrote: post #13

Earlier quoted context omitted.

The thing is, Rust has tools that are easier to use _and_ have great performance _and_ prevent security and stability mistakes.

However Rust is single vendor and single implementation, has a much smaller community and ecosystem than C++, is not standardized, and does not support all of the platforms and use cases that C++ does.

Fair points, but none of them are inherent to the language itself.

Re: Modern C++ Won't Save Us

#27

Post by sanderjd »

932 wrote: post #21
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…

Yeah, agreed. The points in the article are valid , but quirks you learn and get past the first time. I still shoot myself in the foot sometimes even though I don't have a single bare new/malloc without a shared/unique ptr! But that's C++ for you. But, C/C++ is the best option for us for high-performance network processing. We're dabbling with Rust for small applications where we would use Python previously and it's…

> but there's no way we could use Rust for the core application yet

I'd love to hear more information on this! In my mental model, you could just use Go to replace your Python utilities, but Rust might be workable for your core (or at least its designers would like it to be and would like to know why it isn't).

Re: Modern C++ Won't Save Us

#28

Post by Nelson69 »

tedunangst wrote: post #18
jmole wrote: post #15

Question - How does one write microcontroller code (or other memory-mapped I/O code) using a memory-safe language?

By calling unsafe code. :) The semantics and guarantees offered by the interface vary, but that's the short version.

I have over 10 years of professional C++ and helped teach a course on it in college. One of my observations, and I may be off, is that a fair number of C++ users tend to take on a kind of macho attitude about it: it's a hammer for every nail, if you make certain mistakes you shouldn't use it or maybe be programming at all, garbage collection and other safety apparatus are kind of like training wheels while the "big boys" don't need that sort of thing.

I'm being a little snarky here, but if you are truly a macho developer, then crapping out that unsafe code in optimized assembly or C or something is a really really easy time to show off and shouldn't be such a big deal for such a seasoned developer. Instead, the question is always raised in this more insecure way: for that tiny percentage of the time you have to do some bit-banging (and it's usually pretty small and encapsulated on most embedded projects) you had might as well do the whole thing in C or C++.

Re: Modern C++ Won't Save Us

#29

Post by shmerl »

> Nonetheless, the question simply must be how we can accomplish it, rather than if we should try. Even with the most modern C++ idioms available, the evidence is clear that, at scale, it's simply not possible to hold C++ right.

So, how then? That's the main question indeed :)

Re: Modern C++ Won't Save Us

#30

Post by shmerl »

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…

Qt has Rust bindings now. I hope CUDA will get replaced with proper cross GPU alternatives anyway. Rust GPU programming should be also possible.
Post reply on HN