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

Rust and C++ with Steve Klabnik and Herb Sutter [audio]

softwareengineeringdaily.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Rust and C++ with Steve Klabnik and Herb Sutter [audio]

#41

Post by tialaramex »

joaquincabezas wrote: post #35
jb1991 wrote: post #27

Earlier quoted context omitted.

Coding in C++ is very different than it is for C and you should not consider them similar in any way. They are now two very different languages and nearly all the idioms in common use in C are considered bad practice in C++. It has been many years since these two languages could be considered similar.

Exactly this. I've felt it while checking some C++ OSS projects, thinking "wow I am more Java than this, and I don't do Java". This prevented me directly jumping into C++ which would be the natural step coming from C (because in reality it's not the natural step)

One thing that surface tutorials in either C++ or Rust won't get at, which might worry your residual C programmer is: how the fuck can any of this be implemented efficiently on the machine ?

In C it often (too often actually but that's a different rant) feels as though what you wrote just translates directly into what the machine does, no surprises, so then it seems intuitively to make sense that this delivers good performance. And it's not anywhere close to obvious in idiomatic C++ or Rust, where yeah, "more Java" in some sense.

One option is to trust it, it's the fastest option as it's no work but you may find you can't bring yourself to do that.

Another option is to satisfy yourself by measuring, time it, or measure how big it is, now and again when you find something that seems like it ought to be dramatically worse - is it really worse? Huh.

The final option, which is very time intensive, is to learn the depths of how this actually works. That probably means learning assembly language, and a bunch of things about how CPUs work, how memory works, etc. If you never did this for C, I'd suggest not starting now as it's a huge time sink and is often going to shake what you thought you knew. But it's an option if you aren't satisfied by the other options.

Re: Rust and C++ with Steve Klabnik and Herb Sutter [audio]

#42

Post by sylware »

pyrale wrote: post #7
sylware wrote: post #4

[flagged]

> I am sorry, but this is propaganda: rust and c++ are the same evil: computer languages with an obscene syntax complexity. All computer languages are bad, but not all are bad equally, or for the same reasons. That's a fine point you're making.

Exactly.

The metrics here, which seems to be alien to many real people or AI bots here, is that the syntax complexity is directly correlated to the difficulty to write an alternative _real life_ compiler of such language (not to mention the other issues...)

The thing with c++,rust and similar syntaxes, is they are at an absurd and grotesque scale in complexity compared to, for instance, C99 syntax with some bits from c11+ for modern architecture programming (dodging all the ISO tantrums like _generic, typeof, asset on steroid, etc).

Yes those words are fair, and not aknowledging them, or trying to dodge this reality, is bluntly hypocrit or you are the victim here, brain-washed, and I advise you to take a deep breath and reflect on that matter in order to get a better perspective.

Do I say C99 + bits of c11+ is "BETTER", certainly not, I am just saying this is a less worse compromise. And its syntax is already waaaaay too complex and should be simplified already... then c++, rust and similar, owww!

There is no argument or questioning here, only aknowledgement of a disturbing absolute truth and fair critism.

And if fair critism means bad karma here, the problem is not with me, but with the karma.

Re: Rust and C++ with Steve Klabnik and Herb Sutter [audio]

#43

Post by creata »

singularity2001 wrote: post #36
joaquincabezas wrote: post #22

I've been a long time considering that I should learn Rust. I am using Python as main language (for Machine Learning tasks) so I am at the edge: Go with: C++, because I used to code in C (for embedded, 8-bit microcontrollers) when I was younger and also for its possible advantage for learning some CUDA (this last thing is mostly for fun) or Rust, because I have some trauma for kernel panics with bad memory management…

IF you learn C++ I'd suggest to use it as a nicer C, without any std:: or the million other complications. Write your own List / String classes for fun, they can't be much worse than the std ones.

The string class you implement will be worse than the stdlib one, unless you implement small-string optimization, too, which is a massive pain.

Re: Rust and C++ with Steve Klabnik and Herb Sutter [audio]

#44

Post by jb1991 »

tialaramex wrote: post #41
joaquincabezas wrote: post #35

Earlier quoted context omitted.

Exactly this. I've felt it while checking some C++ OSS projects, thinking "wow I am more Java than this, and I don't do Java". This prevented me directly jumping into C++ which would be the natural step coming from C (because in reality it's not the natural step)

One thing that surface tutorials in either C++ or Rust won't get at, which might worry your residual C programmer is: how the fuck can any of this be implemented efficiently on the machine ? In C it often (too often actually but that's a different rant) feels as though what you wrote just translates directly into what the machine does, no surprises, so then it seems intuitively to make sense that this delivers good p…

You are forgetting yet another option which is widespread and common practice among serious C++ developers, which is to use the Compiler Explorer to see how the code directly translates into machine instructions. It is almost normal to always have this open next to your IDE if you care about performance.

Note that most people who use Compiler Explorer don't actually know assembly that well, but you don't need to know it to see what is happening at a basic level, which usually suffices.

However, it is not necessary to care so much about performance in most cases. The language is generally fast compared to other languages, even if you don't try to make it fast -- the compilers and the language spec usually have that outcome. But when you really want to squeeze out the most efficient code, Compiler Explorer is the way most people do it.

Re: Rust and C++ with Steve Klabnik and Herb Sutter [audio]

#45

Post by jb1991 »

singularity2001 wrote: post #36
joaquincabezas wrote: post #22

I've been a long time considering that I should learn Rust. I am using Python as main language (for Machine Learning tasks) so I am at the edge: Go with: C++, because I used to code in C (for embedded, 8-bit microcontrollers) when I was younger and also for its possible advantage for learning some CUDA (this last thing is mostly for fun) or Rust, because I have some trauma for kernel panics with bad memory management…

IF you learn C++ I'd suggest to use it as a nicer C, without any std:: or the million other complications. Write your own List / String classes for fun, they can't be much worse than the std ones.

This is such bad advice.

Re: Rust and C++ with Steve Klabnik and Herb Sutter [audio]

#46

Post by nicce »

sylware wrote: post #42
pyrale wrote: post #7

Earlier quoted context omitted.

> I am sorry, but this is propaganda: rust and c++ are the same evil: computer languages with an obscene syntax complexity. All computer languages are bad, but not all are bad equally, or for the same reasons. That's a fine point you're making.

Exactly. The metrics here, which seems to be alien to many real people or AI bots here, is that the syntax complexity is directly correlated to the difficulty to write an alternative _real life_ compiler of such language (not to mention the other issues...) The thing with c++,rust and similar syntaxes, is they are at an absurd and grotesque scale in complexity compared to, for instance, C99 syntax with some bits from…

> The thing with c++,rust and similar syntaxes, is they are at an absurd and grotesque scale in complexity compared to, for instance, C99 syntax with some bits from c11+ for modern architecture programming (dodging all the ISO tantrums like _generic, typeof, asset on steroid, etc).

The syntax is a tradeoff, almost always. For example, without the lifetime type in Rust, compiler cannot identify even in theory, what is the intended lifetime of that specific type and it cannot guarantee that use-after-free will not happen.

Re: Rust and C++ with Steve Klabnik and Herb Sutter [audio]

#47

Post by nurettin »

lifthrasiir wrote: post #24
bregma wrote: post #18

Earlier quoted context omitted.

> analogous conformance test suites exist and are run automatically I'm not clear on how this is even possible. "Conformance" for C++ means adherence to the published ISO/IEC 14882 standard. In the case of Rust, it's "this is what the compiler does this week". Sure, a third party has built out a CI system for Rust and uses it provide evidence that Rust does what Rust does, but that's nothing similar to having evidenc…

Here the conformance refers to the Ferrocene language specification [1], which is being developed to be something akin to ISO/IEC 14882 for Rust in the future. In fact, this specification and the Ferrocene toolchain is meant to be ISO 26262 or IEC 61508 qualified, so it directly addresses your concern. The comment posted by jamesmunns will do much better job in describing the exact details than mine (both comments ha…

> Quite a lot of people criticizing Rust for the lack of formal standards seem to assume that such standards will immediately improve something

Formal standards aren't just for providing a spec to be used in alternative implementations or somehow proving that the syntax is logically sound.

They are also the process of international representatives vetting for new additions to the language or breaking backwards compatibility which is what I would be criticizing the lack thereof.

Re: Rust and C++ with Steve Klabnik and Herb Sutter [audio]

#48

Post by pyrale »

sylware wrote: post #42
pyrale wrote: post #7

Earlier quoted context omitted.

> I am sorry, but this is propaganda: rust and c++ are the same evil: computer languages with an obscene syntax complexity. All computer languages are bad, but not all are bad equally, or for the same reasons. That's a fine point you're making.

Exactly. The metrics here, which seems to be alien to many real people or AI bots here, is that the syntax complexity is directly correlated to the difficulty to write an alternative _real life_ compiler of such language (not to mention the other issues...) The thing with c++,rust and similar syntaxes, is they are at an absurd and grotesque scale in complexity compared to, for instance, C99 syntax with some bits from…

> they are at an absurd and grotesque scale in complexity

I'm sure you can understand, though, that other people will prioritize different factors in the pros/cons of each language.

For instance, as a dev that's well versed in type systems but with little experience of handling memory, Rust is basically golden compared to C or C++, because I can write code without fear, knowing that all of the discipline C/C++ devs is baked in a type system I'm used to.

> I am just saying this is a less worse compromise

In that sense, when comparing languages with different tradeoffs, people in different contexts will make different choices. A compromise is necessarily context-bound, and saying which compromise you promote is just another way to talk about your own context.

Re: Rust and C++ with Steve Klabnik and Herb Sutter [audio]

#49

Post by lifthrasiir »

nurettin wrote: post #47
lifthrasiir wrote: post #24

Earlier quoted context omitted.

Here the conformance refers to the Ferrocene language specification [1], which is being developed to be something akin to ISO/IEC 14882 for Rust in the future. In fact, this specification and the Ferrocene toolchain is meant to be ISO 26262 or IEC 61508 qualified, so it directly addresses your concern. The comment posted by jamesmunns will do much better job in describing the exact details than mine (both comments ha…

> Quite a lot of people criticizing Rust for the lack of formal standards seem to assume that such standards will immediately improve something Formal standards aren't just for providing a spec to be used in alternative implementations or somehow proving that the syntax is logically sound. They are also the process of international representatives vetting for new additions to the language or breaking backwards compat…

Most "international" standards are international only because the corresponding standard organization is ultimately operated by multiple nation-states. In reality the organization just appoints some experts to write the standard and brand it with their blessing, so the standardization process is hardly international. For language standards, those experts typically include original designers and whoever wanted to standardize the language. (Otherwise why would anyone want to join this tedious process?) A diverse group of experts is very rare for such standards.

It is another myth or fetishism that international standards have some inherent mechanism to ensure the compatibility. Such quality can be only maintained when standard editors take care of that and there is a comparable industry support. Missing any one, the compatibility can be easily broken, and conversely any specification---formally written or not---can maintain the compatability when both are satisfied.

Re: Rust and C++ with Steve Klabnik and Herb Sutter [audio]

#50

Post by sylware »

pyrale wrote: post #48
sylware wrote: post #42

Earlier quoted context omitted.

Exactly. The metrics here, which seems to be alien to many real people or AI bots here, is that the syntax complexity is directly correlated to the difficulty to write an alternative _real life_ compiler of such language (not to mention the other issues...) The thing with c++,rust and similar syntaxes, is they are at an absurd and grotesque scale in complexity compared to, for instance, C99 syntax with some bits from…

> they are at an absurd and grotesque scale in complexity I'm sure you can understand, though, that other people will prioritize different factors in the pros/cons of each language. For instance, as a dev that's well versed in type systems but with little experience of handling memory, Rust is basically golden compared to C or C++, because I can write code without fear, knowing that all of the discipline C/C++ devs i…

Exactly, and my point is critism of those tradeoffs by shining light on some of their "cosmical scale"(the word is fair) costs... somehow completely ignored in this articles of this type... how convenient...

People are not equal in experience and knowledge, and it is very important to ring a different bell here to give them a significant other perspective which will impact their own choices... those very choices which other people will have to suffer if it happens they code critical open source software...

Post reply on HN