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

81–89 of 89 posts

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

#81

Post by Manishearth »

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.

Java/Go use a GC and have certain design principles which place an upper bound on the speed unless you want to break backwards compatibility.

Rust does not. The main issue with Rust is that we haven't gotten around to optimizing the IR properly. It's something which can be done backwards compatibly without changing the actual language at all.

The only design component I can think of which leads to bad perf is the drop flag. And that's something that should go away soon (Rust doesn't guarantee that destructors will run using this model only, so it can be changed)

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

#82

Post by Manishearth »

steveklabnik wrote: post #60
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.

We're already faster than C in some benchmarks, (and slower in others, of course) and since we use LLVM on the backend, we can take advantage of all of the performance work that's put into Clang and friends as well.

I also forsee a significant speedup in complex applications caused by programmers being more free to do pointer gymnastics because they know that there won't be use after free or anything (as compared to using refcounting everywhere or a GC).

(http://manishearth.github.io/blog/2015/05/03/where-rust-real... has an example for others reading this thread)

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

#83

Post by Manishearth »

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?

Wait, really? Wow. I always thought Rust was slower to compile.

Huh.

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

#84

Post by Manishearth »

putzdown wrote: post #26

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

I'd love to too.

One way to do this would be to get a Rust aficionado who has written a significant amount of Rust code and knows all the nooks and crannies to work with a C++ counterpart on such an article. If both parties are mature enough (zealotry allowed on both sides, but constructive zealotry :P), we can get a decent post which addresses either side and has all the points and counterpoints that might come up in a discussion.

I'm not exactly a seasoned Rustacean, but I'd be more than happy to try this out with someone. (might take some time for me to get to it though, intern just started and I have some other Rust blog posts I want to get done first)

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

#85

Post by steveklabnik »

Manishearth wrote: post #83
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?

Wait, really? Wow. I always thought Rust was slower to compile. Huh.

Yeah, people say Rust is slow to compile, but when they say that, they aren't generally talking about C++.

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

#86

Post by cicero »

azth wrote: post #76
cicero wrote: post #64

Earlier quoted context omitted.

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

> Today, I see similar reactions to leading edge technologies and languages that are difficult to understand, whether they be FP, Rust, or Haskell. I wouldn't lump all three together just because they may happen to be somewhat difficult to understand. I see your point regarding FP (and Haskell happens to be an FP language). However, Rust is a multi-paradigm language, just the way C++ is. Time and time again in my day…

I didn't mean to imply that Rust was only FP; I was just listing examples of current leading edge technologies and languages.

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

#87

Post by karmakaze »

Manishearth wrote: post #80
igouy wrote: post #45

Earlier quoted context omitted.

At this point, the only response needed to "rust is slow" claims is - rustc is beta. Come back when it's cooked :)

Technically Rust will be 1.0 by the end of the week; but that won't magically make it faster. The real point to be made here is that Rust can be optimized without dropping any design principles. It's a solvable problem. On the other hand, Java and Go's design puts a limit on the optimization you can use. (Also, those benchmarks are a year old IIRC, Rust might actually have sped up in that time!)

Indeed for x64-one-core[1] the geometric mean is now closer to Fortran and Ada.

[1] http://benchmarksgame.alioth.debian.org/u64/which-programs-a...

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

#88

Post by igouy »

jcranmer wrote: post #53
oldmanjay wrote: post #8

I get that this is a translation but it's very poorly written even considering that. lots of repetitive conclusion jumping in what I can only assume is an attempt to baffle the reader into uncritically accepting what appears to be a largely unsupported opinion. the only evidence the post seems to offer is that rust is slow because it showed up 5th in a set of microbenchmarks. everything else is rhetorical garbage, fr…

Correction: a set of microbenchmarks whose own documentation emphatically states the difficulty of drawing any conclusions from those results. Comparing different programming languages is notoriously difficult, particularly since the metric is underdefined. The best programmers might write faster code in language A compared to language B, but if average programmers write code that is no faster, does that mean languag…

> the difficulty of drawing any conclusions from those results The difficulty of drawing general conclusions from program performance measurements -- not just "those results".

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

#89

Post by igouy »

Manishearth wrote: post #80
igouy wrote: post #45

Earlier quoted context omitted.

At this point, the only response needed to "rust is slow" claims is - rustc is beta. Come back when it's cooked :)

Technically Rust will be 1.0 by the end of the week; but that won't magically make it faster. The real point to be made here is that Rust can be optimized without dropping any design principles. It's a solvable problem. On the other hand, Java and Go's design puts a limit on the optimization you can use. (Also, those benchmarks are a year old IIRC, Rust might actually have sped up in that time!)

> Also, those benchmarks are a year old IIRC Why didn't you check the commit age in the repo?
Post reply on HN