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

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

viva64.com

Post reply on HN
Print view View original

61–70 of 89 posts

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

#61

Post by [deleted] »

EugeneOZ wrote: post #55
astrodust wrote: post #36

Earlier quoted context omitted.

It also means they know what they're talking about. Many of the points are valid, but it's important to remember Rust is not even released. Java 1, Ruby 1, Perl 1, Python 1 were all pretty terrible compared to their current manifestations.

They know only 1 part of the bridge, but without second part is not the bridge, but shameful biased grunt "oh oh, will we still make money on C++ or we need to learn something new to keep our income?". And question is answered before they company existed. They even dare enough to recommend others don't learn Rust in favor of C++ - so biased recommendation makes whole grunt even more pointless. Don't get me wrong, I u…

[deleted]

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

#62

Post by phaylon »

steveklabnik wrote: post #56
frankzinger wrote: post #49

Earlier quoted context omitted.

How does Rust's compile times compare with those of C++?

We don't have a whole lot of data, but generally faster. I can't seem to find the blog post now, but someone ported their raytracer from C++ to Rust, and the compile time was... half? I think?

Do you mean this[1] port? I can't remember one that had statistics on incremental builds during development, unfortunately.

[1] https://ruudvanasseldonk.com/2014/10/20/writing-a-path-trace... (See "Performance")

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

#63

Post by steveklabnik »

phaylon wrote: post #62
steveklabnik wrote: post #56

Earlier quoted context omitted.

We don't have a whole lot of data, but generally faster. I can't seem to find the blog post now, but someone ported their raytracer from C++ to Rust, and the compile time was... half? I think?

Do you mean this[1] port? I can't remember one that had statistics on incremental builds during development, unfortunately. [1] https://ruudvanasseldonk.com/2014/10/20/writing-a-path-trace... (See "Performance")

Yes! That one.

Right now, Rust only builds each crate in paralell, we don't support incremental re-builds within crates. There's an RFC already though, and build times are gonna be a big focus of the next release cycle or two.

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

#64

Post by cicero »

steveklabnik wrote: post #12

I left a comment on Reddit that I'll adapt here. It's really intended at the Rust community specifically, but I think the message is still worthwhile anyway: Not everyone is going to like Rust. That's totally okay. I've seen language communities, especially newer ones where people are particularly passionate, essentially turn into... this is a bit strong, but mini-cults. Where if you don't like the language, you're o…

I've been programming for 35 years, and I remember when object-oriented programming advocates seemed cult-like. As it turned out, O-O is a very useful tool, but it is not the ultimate programming paradigm. Time has shown that the early adopters of O-O were mostly justified in their enthusiasm, but tended to overstate the benefits of the technology. The O-O naysayers had concerns about performance, which is an issue in some O-O languages, but one that C++ solved. They also had concerns that O-O was hard to understand, but that is something that has been mostly solved through education. These days, the expectation is that a good programmer understands O-O.

Today, I see similar reactions to leading edge technologies and languages that are difficult to understand, whether they be FP, Rust, or Haskell. Time will tell whether these things break into the mainstream as did O-O, C++, and Java. I personally think that Rust is onto something, but it is too early to know how much impact it will have on the mainstream. Who knows, 10 years from now, we may see a dominant OS and application ecosystem written completely in Rust that has a level of quality seldom seen today. Or maybe we will see some of the ideas in Rust incorporated into a future version of C++. Or maybe Rust and its ideas will prove to be too impractical and will fade away.

I hope to have the time to learn and use Rust soon, but I certainly understand those who prefer to wait and see. What I don't care for is a knee-jerk reaction against something because it is unfamiliar.

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

#65

Post by lambdaelite »

monocasa wrote: post #57
lambdaelite wrote: post #52

Earlier quoted context omitted.

To me, it seems like in the future Rust could occupy the same niche as Java + RTSJ does presently. I'm just not clear on how or why Rust would be sufficiently better to overcome the track record of Java + RTSJ.

JITs and interpreters suck for realtime, and there's only so many optimizations that an AOT compiler can do to a Java codebase (hence why JITs ar so prevalent for Java). Pushing all of these verifications into compile time significantly reduces the run time requirements. Honestly I see Rust as (potentially, down the road) being a better, less verbose Ada than a better C++ or Java. You tend to write Rust code much lik…

Both JamaicaVM and PERC seem to have favorable requirements when run with AOT compilation, and the JIT compilation didn't seem too onerous either. What problems have you run into?

I ask because I'm in the process of spec'ing out a safety critical medical device, and JamaicaVM is the lead candidate at the moment.

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

#66

Post by duaneb »

rwj wrote: post #54
duaneb wrote: post #24

Earlier quoted context omitted.

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 th…

This is an interesting question, but I'm not convinced it is the case. Many people have argued that Java, Ruby, (insert favorite language here) will one day match the speed of C, it just requires more advanced tooling, but that promise has never been fulfilled. Many abstractions come with a cost, just look at the jump between C and C++. Perhaps Rust will match the speed of C, but I don't think it is certain.

> Many people have argued that Java, Ruby, (insert favorite language here) will one day match the speed of C, it just requires more advanced tooling, but that promise has never been fulfilled.

The primary block to this is memory management. Rust allows a superset of C/C++ memory management techniques, so there is literally no technical reason you shouldn't be able to port a c program to the equivalent rust program. Unlike java, go, etc., this doesn't break new ground in terms of optimization but rather verification of existing systems programming techniques.

To put this another way, you could write a rust -> c++ compiler and "automagically" get the speed of c++, but the same could not be said of Java.

The one area of which I'm unaware is pointer aliasing (in unsafe code, obviously). I am not entirely sure how well rust can restrict the types to optimize exclusive access to a memory region ala the c `restrict` keyword. But there's always inline assembly if that fails.

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

#68

Post by steveklabnik »

duaneb wrote: post #66
rwj wrote: post #54

Earlier quoted context omitted.

This is an interesting question, but I'm not convinced it is the case. Many people have argued that Java, Ruby, (insert favorite language here) will one day match the speed of C, it just requires more advanced tooling, but that promise has never been fulfilled. Many abstractions come with a cost, just look at the jump between C and C++. Perhaps Rust will match the speed of C, but I don't think it is certain.

> Many people have argued that Java, Ruby, (insert favorite language here) will one day match the speed of C, it just requires more advanced tooling, but that promise has never been fulfilled. The primary block to this is memory management. Rust allows a superset of C/C++ memory management techniques, so there is literally no technical reason you shouldn't be able to port a c program to the equivalent rust program. U…

&mut pointers ensure that they are the _only_ reachable alias to a given bit of memory.

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

#69

Post by ThatGeoGuy »

semi-extrinsic wrote: post #51
moonchrome wrote: post #23

>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 an…

There's a lot of the "write X% in slowlang and (100-X)% in fastlang" thrown around, but I have to say, I've not seen too many such projects around.

Actually, in the CHICKEN Scheme community, this is done quite often, though you don't see it nearly as much because of how transparent it ends up being. Mostly stuff is written in Scheme / R5RS when possible, and C bindings to a faster library or implementation are exported using the bind egg when speed is of critical importance.

This is obviously not the norm, as the bind egg is very good, but it's definitely out there. Makes me wish that there were other languages which offered something similar to bind, but alas CHICKEN is the only one I know of thus far.

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

#70

Post by duaneb »

steveklabnik wrote: post #68
duaneb wrote: post #66

Earlier quoted context omitted.

> Many people have argued that Java, Ruby, (insert favorite language here) will one day match the speed of C, it just requires more advanced tooling, but that promise has never been fulfilled. The primary block to this is memory management. Rust allows a superset of C/C++ memory management techniques, so there is literally no technical reason you shouldn't be able to port a c program to the equivalent rust program. U…

&mut pointers ensure that they are the _only_ reachable alias to a given bit of memory.

So, it's functionally equivalent to a "restrict" keyword in unsafe mode? (i.e. you can alias without the compiler being able to prove it as if you weren't aliasing.)
Post reply on HN