Criticizing the Rust Language, and Why C/C++ Will Never Die • Hacker News Board

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#21

Post by lambdaelite » Tue, May 12, 2015, 3:35 PM UTC

vowelless wrote: post #13

outworlder wrote: post #9

Earlier quoted context omitted.

> "is a huge advantage over Rust for mission critical and safety critical areas" There's no C/C++. They are entirely different languages (even if C is supposed to be a subset). Not exactly suitable for mission critical systems. The fact that they are used for that is more due to the fact that they can interface with hardware at a fairly low level and the amount of engineers with C (and nowadays, C++) knowledge. The '…

> There's no C/C++. They are entirely different languages (even if C is supposed to be a subset). I think the OP is trying to say that both C and C++ have international standards. > Not exactly suitable for mission critical systems. The fact that they are used for that is more due to the fact that they can interface with hardware at a fairly low level and the amount of engineers with C (and nowadays, C++) knowledge.…

Ditto.

If Rust had a formal standard, and had the tool ecosystem, then I could see it being an interesting possibility for critical systems, certainly for the same places that Java + RTSJ would be appropriate. I won't be the first one to try and push a Rust-powered device through regulatory approval though.

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#22

Post by Alupis » Tue, May 12, 2015, 3:35 PM UTC

outworlder wrote: post #9

lambdaelite wrote: post #7

Earlier quoted context omitted.

That C/C++ have a formal standard and have an entire tool ecosystem is a huge advantage over Rust for mission critical and safety critical areas (not that Rust would be used for SC applications).

> "is a huge advantage over Rust for mission critical and safety critical areas" There's no C/C++. They are entirely different languages (even if C is supposed to be a subset). Not exactly suitable for mission critical systems. The fact that they are used for that is more due to the fact that they can interface with hardware at a fairly low level and the amount of engineers with C (and nowadays, C++) knowledge. The '…

> There's no C/C++. They are entirely different languages (even if C is supposed to be a subset).

C++ is a subset of C, not the other way around.

> the fact that they can interface with hardware at a fairly low level

That's certainly one reason. Others include raw performance (think real-time safety-critical applications), no funny abstractions, tighter memory footprint, more flexibility, etc.

> and the amount of engineers with C (and nowadays, C++)

While I believe there are a number of C++ engineers out there, I'd wager that the number of competent C language engineers has dwindled over the years. Sure, everyone learns some C, but to know it well enough to write embedded real-time safety-critical systems is a whole different game. (not to mention the number of Java engineers has greatly outpaced even C++ engineers, thanks to University teaching Java, Android's dominance, and the lower barrier to entry).

> The 'formal' standard doesn't help you much when there's so much undefined behavior.

The formal standard defines what is undefined. Your safety-critical code shouldn't rely on some compiler-specific quirks or some magical code, but rather it should stay within the bounds of well-defined behavior.

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#23

Post by moonchrome » Tue, May 12, 2015, 3:36 PM UTC

>OK, but doesn't it imply that I do not need Rust at all because I could write 90% of my code in Go and the rest 10% in C? Only silver bullet seekers and airy-fairy (t)he(o)retics will use Rust just for the sake of feeling contented about having 100% of a program written in seemingly one language.

Have you actually tried to do that or understand what Rust unsafe code means ? Interfacing between different run-times and memory management systems is complicated (and often slow), rust unsafe is simply giving up on compiler verification.

He misses the point on premature optimization entirely.

>For Android, it's also hardly probable, but for a different reason: there is way more than one architecture there, so JVM will do much better

And yet people write C++ code for Android, or is he arguing that Rust won't replace Java on Android (that's a pretty big straw man)

>I can't but remind you for one more time that the source of troubles is usually in humans, not technology . If your C++ code is not good enough or Java code is painfully slow, it's not because the technology is bad - it's because you haven't learned how to use it right. That way, you won't be satisfied with Rust either, but just for some other reasons. Isn't it easier to learn how to use more popular tools and start liking them?

Different tools require different amounts of effort to get things "right" and it's not simply a matter of "learning things" - humans have limited brain power - there's only so many things you can be aware of at any time - good tools reduce the number of those things required to get the job done - C++ is bad at this.

I agree with some of his points about the ergonomics and the implementation/tooling but I also feel like those are just growing pains - now is the time you start working on Rust for your weekend github project and start paving the way for actual real world use by early adopters which is at least a year off from this point.

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#24

Post by duaneb » Tue, May 12, 2015, 3:37 PM UTC

VeejayRampay wrote: post #2

Regarding speed, I am not sure it really is the bee's knees. The existence of LLVM and the likes, the fact that Javascript got a HUGE speedup in the past 5 years seems to be an indication that it is by essence a factor that can be tuned eventually. I doubt a "slow" language will ever get to be C in that regard, but I also doubt C will ever provide the kind of ease of mind that a more inherently modern and secure lang…

It's a little silly to quibble about speed when the language is still being designed. There is plenty of time to optimize the language; there's not much technical barrier to matching the speed of c/c++, especially when allowing unsafe code.

However, something I've noticed from the land of C++ is some peoples' issue with the idea that thread safety is difficult. In fact, they appear to downright bristle at the idea that they might not write perfect code and that they might lose the ability to run with fast-but-not-correct code. I don't think this is a conscious reaction, but it seems similar to what's going on in the article.

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#25

Post by steveklabnik » Tue, May 12, 2015, 3:38 PM UTC

Alupis wrote: post #22

outworlder wrote: post #9

Earlier quoted context omitted.

> "is a huge advantage over Rust for mission critical and safety critical areas" There's no C/C++. They are entirely different languages (even if C is supposed to be a subset). Not exactly suitable for mission critical systems. The fact that they are used for that is more due to the fact that they can interface with hardware at a fairly low level and the amount of engineers with C (and nowadays, C++) knowledge. The '…

> There's no C/C++. They are entirely different languages (even if C is supposed to be a subset). C++ is a subset of C, not the other way around. > the fact that they can interface with hardware at a fairly low level That's certainly one reason. Others include raw performance (think real-time safety-critical applications), no funny abstractions, tighter memory footprint, more flexibility, etc. > and the amount of eng…

> C++ is a subset of C, not the other way around.

This is not true, the two languages have diverged: http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#26

Post by putzdown » Tue, May 12, 2015, 3:40 PM UTC

It's true that C/C++ will never die. Not everyone loves them, but they're both good languages and they both have their place. Part of that place is due to mere tradition, mere established-ness, but part of it is real merit in terms of speed and directness.

It's true that Rust aficionados tend to come across as religious zealots. Most "up and coming" language advocates do. This is a case where zealotry is understandable and maybe necessary. When you've got a good thing that's an underdog in a world ruled by the familiar, the status quo, zealotry is the only way to break through the complacency.

It's also true that between awkward English, poor structure, and a lack of rigor in argumentation, this article comes across as drum-banging rather than thoughtful. I'd like to see an article that respects Rust, respects C/C++, and offers a measured, well-argued case for how they compare and what their prospects are in the long term when "establishedness" becomes less relevant (i.e. when Rust, through becoming more widespread, becomes less hampered by not having a large community or job base).

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#27

Post by outworlder » Tue, May 12, 2015, 3:45 PM UTC

Alupis wrote: post #22

outworlder wrote: post #9

Earlier quoted context omitted.

> "is a huge advantage over Rust for mission critical and safety critical areas" There's no C/C++. They are entirely different languages (even if C is supposed to be a subset). Not exactly suitable for mission critical systems. The fact that they are used for that is more due to the fact that they can interface with hardware at a fairly low level and the amount of engineers with C (and nowadays, C++) knowledge. The '…

> There's no C/C++. They are entirely different languages (even if C is supposed to be a subset). C++ is a subset of C, not the other way around. > the fact that they can interface with hardware at a fairly low level That's certainly one reason. Others include raw performance (think real-time safety-critical applications), no funny abstractions, tighter memory footprint, more flexibility, etc. > and the amount of eng…

> C++ is a subset of C, not the other way around.

I can't see how this statement could possibly be true.

> no funny abstractions

Really? Maybe I suck at C++, but I can't meaningfully reason about template-heavy code. Not about the run-time performance, nor resource consumption. STL and Boost are beyond funny if you ask me.

> The formal standard defines what is undefined. Your safety-critical code shouldn't rely on some compiler-specific quirks or some magical code, but rather it should stay within the bounds of well-defined behavior.

Agreed. But take a look at the specification and you'll be amazed on just how much stuff is left for the actual implementation to figure out.

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#28

Post by Alupis » Tue, May 12, 2015, 3:46 PM UTC

steveklabnik wrote: post #25

Alupis wrote: post #22

Earlier quoted context omitted.

> There's no C/C++. They are entirely different languages (even if C is supposed to be a subset). C++ is a subset of C, not the other way around. > the fact that they can interface with hardware at a fairly low level That's certainly one reason. Others include raw performance (think real-time safety-critical applications), no funny abstractions, tighter memory footprint, more flexibility, etc. > and the amount of eng…

> C++ is a subset of C, not the other way around. This is not true, the two languages have diverged: http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

You are right, they have diverged. However my initial statement was/is true, as C++ started as a subset of C (even though the two are totally incompatible for all non-trivial programs today).

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#29

Post by outworlder » Tue, May 12, 2015, 3:49 PM UTC

vowelless wrote: post #15

s_baby wrote: post #10

Earlier quoted context omitted.

A formal standard that has undefined behavior and is apparently difficult to implement a compiler for. It seems C++ is popular for mission critical software despite its standards.

You have to be a little smart about C++. Avoid using anything dynamic (including exceptions, dynamic casting, etc).

Basically, avoid using C++, except for .

The way Qt does is actually quite pleasant to work with, but they avoid most language features and roll their own (QObject, I'm looking at you), even including their own preprocessor.

Re: Criticizing the Rust Language, and Why C/C++ Will Never Die

#30

Post by lambdaelite » Tue, May 12, 2015, 3:51 PM UTC

outworlder wrote: post #27

Alupis wrote: post #22

Earlier quoted context omitted.

> There's no C/C++. They are entirely different languages (even if C is supposed to be a subset). C++ is a subset of C, not the other way around. > the fact that they can interface with hardware at a fairly low level That's certainly one reason. Others include raw performance (think real-time safety-critical applications), no funny abstractions, tighter memory footprint, more flexibility, etc. > and the amount of eng…

> C++ is a subset of C, not the other way around. I can't see how this statement could possibly be true. > no funny abstractions Really? Maybe I suck at C++, but I can't meaningfully reason about template-heavy code. Not about the run-time performance, nor resource consumption. STL and Boost are beyond funny if you ask me. > The formal standard defines what is undefined. Your safety-critical code shouldn't rely on so…

> But take a look at the specification and you'll be amazed on just how much stuff is left for the actual implementation to figure out.

Which is why the coding standard for a critical project will disallow the use of things that can lead to undefined behavior.