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

I think C++ is still a desirable coding platform compared to Rust

lucisqr.substack.com

Post reply on HN
Print view View original

81–90 of 110 posts

Re: I think C++ is still a desirable coding platform compared to Rust

#81

Post by steveklabnik »

synergy20 wrote: post #79
steveklabnik wrote: post #78

Earlier quoted context omitted.

You absolutely can get Rust codegen down to as small as you’d ever need: https://news.ycombinator.com/item?id=34032824

that's for MCU and yes, as it does not use rust's stdlib. there are lots of embedded systems that run with glibc or musl shared libraries, if rust is used there, it will blow up the storage space with just a few executables due to the static stdlibs.

I don’t understand why techniques valid in small spaces aren’t also valid in slightly larger spaces.

If you don’t have the budget for the standard library, don’t use it. If you somehow have the budget for glibc and not the rust standard library, call into glibc instead of the rust standard library.

Re: I think C++ is still a desirable coding platform compared to Rust

#82

Post by steveklabnik »

Jyaif wrote: post #33
BanTheBastards wrote: post #9

Earlier quoted context omitted.

Speak for yourself: I'm not returning to the world of "discipline" (aka lost productivity) without a damn good reason to carry on existing codebases. It's just a waste of a good coder and certainly of good time.

In C++ discipline is optional. In Rust it's mandatory.

I think this is amusing because both directions completely work:

In C++, you can do whatever. Rust forces you do to some things. No discipline required by C++, absolutely required by Rust.

In C++, you can do whatever. Rust forces you to do some things. This means you must have discipline in C++, or you will do bad things. But in Rust, you can do whatever you want, the compiler has your back.

Re: I think C++ is still a desirable coding platform compared to Rust

#83

Post by pandaman »

titzer wrote: post #39

> Are we talking about safety against hackers? The large majority of C++ applications are non-public facing. That is like saying that most screws aren't load bearing, so it's fine if they fail 30% of the time. The way engineering works is that people build on reusable pieces. For example, several bugs in libjpeg have caused serious vulnerabilities in many applications, including web browsers. You cannot predict how s…

C++ programs do not fail 30% of the time though. Safety concerns matter when the program is actively being attacked, the reason libjpeg had these bugs in the first place was that it works just fine in absence of attacks so nobody bothered to find them. It would be nice if by switching to some magic language we've got safety at no cost but it's not the case in the reality.

Re: I think C++ is still a desirable coding platform compared to Rust

#84

Post by aldanor »

distcs wrote: post #28

> In many years of coding C++, very rarely I experienced a stack overflow or segmentation fault. It is literally not an issue in every codebase I have worked with. Is this true for most people though? What do you think about this quote? Frankly I've seen a lot of segmentation fault issues with C++ projects. Granted much of it can be detected pre-emptively with good tools and when a segfault happens, I can debug it qu…

As someone said above in the thread, segfaults is what you get if you're lucky. If you're unlucky, you get silent memory corruption that you will eventually notice through bugs popping up in seemingly unrelated parts of code.

Re: I think C++ is still a desirable coding platform compared to Rust

#85

Post by aldanor »

cmrdporcupine wrote: post #64
Yoric wrote: post #46

Earlier quoted context omitted.

Yeah, I've seen C++ engineers pick up Rust in a few weeks. And one JavaScript engineer, too, defying my prejudice :)

I picked up Rust in a few days/weeks, but ... I'd say not totally idiomatically. It actually takes a while to really learn the ins-and-outs of the right way to express certain patterns. If the codebase that the eng is being brought into is established with good conventions, I could see it happening quickly though.

I've seen engineers with prior C++ background and barely any knowledge of Rust brought in to work on a well established and large Rust codebase with coding guidelines and the such, and they were rocking in less than a month.

Re: I think C++ is still a desirable coding platform compared to Rust

#86

Post by synergy20 »

steveklabnik wrote: post #81
synergy20 wrote: post #79

Earlier quoted context omitted.

that's for MCU and yes, as it does not use rust's stdlib. there are lots of embedded systems that run with glibc or musl shared libraries, if rust is used there, it will blow up the storage space with just a few executables due to the static stdlibs.

I don’t understand why techniques valid in small spaces aren’t also valid in slightly larger spaces. If you don’t have the budget for the standard library, don’t use it. If you somehow have the budget for glibc and not the rust standard library, call into glibc instead of the rust standard library.

glibc can be shared by 20 c executables.

rust stdlib will be bundled with those 20 rust executables, they blow up quickly.

mcu does not use stdlib of rust, it uses no-std, c++ has its own nonstdlib as well, on mcu they're similar.

Re: I think C++ is still a desirable coding platform compared to Rust

#87

Post by titzer »

pandaman wrote: post #83
titzer wrote: post #39

> Are we talking about safety against hackers? The large majority of C++ applications are non-public facing. That is like saying that most screws aren't load bearing, so it's fine if they fail 30% of the time. The way engineering works is that people build on reusable pieces. For example, several bugs in libjpeg have caused serious vulnerabilities in many applications, including web browsers. You cannot predict how s…

C++ programs do not fail 30% of the time though. Safety concerns matter when the program is actively being attacked, the reason libjpeg had these bugs in the first place was that it works just fine in absence of attacks so nobody bothered to find them. It would be nice if by switching to some magic language we've got safety at no cost but it's not the case in the reality.

> we've got safety at no cost

No one ever said that safety was zero-cost. The article mentions bounds checks, but gives no measurements. Have they ever measured? Most data I've seen is that bounds checks cost less than 1% in real-world code. I will boldly assert that there has never been a product that couldn't be shipped because that 1% caused them to miss a performance goal. We could get into the weeds and go off on a tangent about linear algebra kernels and loop transformations being slower / more difficult with bounds checks, but that is an absolute niche case that can be solved with different techniques like loop versioning and static assertions.

Re: I think C++ is still a desirable coding platform compared to Rust

#88

Post by steveklabnik »

synergy20 wrote: post #86
steveklabnik wrote: post #81

Earlier quoted context omitted.

I don’t understand why techniques valid in small spaces aren’t also valid in slightly larger spaces. If you don’t have the budget for the standard library, don’t use it. If you somehow have the budget for glibc and not the rust standard library, call into glibc instead of the rust standard library.

glibc can be shared by 20 c executables. rust stdlib will be bundled with those 20 rust executables, they blow up quickly. mcu does not use stdlib of rust, it uses no-std, c++ has its own nonstdlib as well, on mcu they're similar.

Yes, I understand what you're saying. I am saying that if you find yourself in that situation, don't use the Rust standard library. Your Rust programs can share glibc with your C programs just fine. This isn't a disqualifying situation for Rust. Heck, when you use the Rust standard library, dynamically linking to glibc is the norm!

Re: I think C++ is still a desirable coding platform compared to Rust

#89

Post by pandaman »

titzer wrote: post #87
pandaman wrote: post #83

Earlier quoted context omitted.

C++ programs do not fail 30% of the time though. Safety concerns matter when the program is actively being attacked, the reason libjpeg had these bugs in the first place was that it works just fine in absence of attacks so nobody bothered to find them. It would be nice if by switching to some magic language we've got safety at no cost but it's not the case in the reality.

> we've got safety at no cost No one ever said that safety was zero-cost. The article mentions bounds checks, but gives no measurements. Have they ever measured? Most data I've seen is that bounds checks cost less than 1% in real-world code. I will boldly assert that there has never been a product that couldn't be shipped because that 1% caused them to miss a performance goal. We could get into the weeds and go off o…

>Have they ever measured?

Yes.

>Most data I've seen is that bounds checks cost less than 1% in real-world code

So? I don't know where you got you data, but the point of the article is that you don't have to pay for the stuff you don't need. Otherwise we could as well use Java or VBA because "most data" says that programs spend 99% of time waiting on IO. If your data shows that then go ahead and use it, other people have other data apparently.

Re: I think C++ is still a desirable coding platform compared to Rust

#90

Post by steveklabnik »

titzer wrote: post #87
pandaman wrote: post #83

Earlier quoted context omitted.

C++ programs do not fail 30% of the time though. Safety concerns matter when the program is actively being attacked, the reason libjpeg had these bugs in the first place was that it works just fine in absence of attacks so nobody bothered to find them. It would be nice if by switching to some magic language we've got safety at no cost but it's not the case in the reality.

> we've got safety at no cost No one ever said that safety was zero-cost. The article mentions bounds checks, but gives no measurements. Have they ever measured? Most data I've seen is that bounds checks cost less than 1% in real-world code. I will boldly assert that there has never been a product that couldn't be shipped because that 1% caused them to miss a performance goal. We could get into the weeds and go off o…

What is more important than "are bounds checks expensive or not" is that Rust gives you tools to do both, just like C++ gives you tools that do both. The defaults are flipped, but both languages are equally capable.

Dropbox famously found bounds checks to be expensive in one part of their Rust code, so they introduced the equivalent of a feature flag to toggle them.

Post reply on HN