> I find it funny and think it's pretty telling that there are bold claims made that are only crossed out after the author is corrected
... What else would you expect? The author observed something, drew a mistaken conclusion, wrote it up, and then had the mistake pointed out, and so retracted. I can't imagine the author realised their claims were wrong before it was pointed out, so of course they're only going to cross them out after being corrected. Of course, it's rather unfortunate that an incorrect write-up is being upvoted to the top of HN but that's not the author's problem (other than the choice of the rather clickbaity title...).
For the specifics of this post, there's some subtle differences between how Rust and C++ behave that could easily explain how the author observed differing behaviour and thus jumped to the conclusion, as explored on /r/rust: https://www.reddit.com/r/rust/comments/63ijkw/rust_optimizat...
Fortunately the overwhelming majority of the community isn't afraid to call this post out, judging by the comments at https://www.reddit.com/r/rust/comments/63ijkw/rust_optimizat... :) I've never seen the author engage with the Rust community in any great capacity (they're not a regular in any forum that I frequent, and I can't name any libraries that they've written), so I wish he'd take the time to learn Rust more before blogging about it.
> I can't imagine the author realised their claims were wrong before it was pointed out
It should be noted that the Rust community team has an open offer to proofread the draft of any Rust-related blog post to help ensure technical accuracy, specifically to help prevent embarrassing things like this. :P Preventing the generation of misinformation is cheaper than curing its dissemination, after all. I've already reached out to the author to make sure they're aware of this offer for the future.
> You could technically interpret it as you did, but only a contrarian would do that.
Or you could have been more clearer.
I didn't intend any animosity, but you clearly do.
> If you want more people to support rust
I don't care whether more people support Rust or not. I am just fighting the spectacular amount of disinformation in this thread by malicious actors that have never used Rust.
> Putting B after A is not swapping them, it is putting the element B so it is right after A.
Then you should have written that instead. Take the pointer in the vector right after A, and swap it with B. That way, A is now right before B, and B is now right after A.
> You put it in quotes and didn't mention any paraphrasing. Linus didn't write it.
I think it's a fair characterization of what was said. Feel free, as everyone is, to read the entire thread again. I'm not a journalist. You have the primary source at your finger tips!
> Can you point out the normative document that provides these guarantees?
Your rate of misreading & over-attribution with the seeming intent to inflame is high.
Trying to be enough of a troll to rollback a bit the perception Rust has a
welcoming community?
If you/anyone is curious about a multi-prog.lang project starting from structure
and later building arsenals in the senses here, there are worse places to start
than the 25+ year history of https://en.wikipedia.org/wiki/OpenMP . There may
be records to be found of board meetings/rationales discussing trade-offs &
limitations.
And yet, the Rust community takes it seriously, issuing a CVE, a point release and a blog post. You won't find these 3 from all 3 major C++ implementations (clang, gcc and msvc) because they don't take the issue as seriously because their spec says they don't have to.
Rust can't guarantee shit but at least they do shit when there's a problem. They take accountability for their shit.
You keep harping on minor nitpicks, but you can't escape the fact that the C++ community did not take this issue as seriously as Rust did. Therefore it is meaningless to compare CVEs across the two ecosystems, which was the substance of the top level comment.
> I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. I've often wondered how this can be possible
> Is the issue primarily with parent’s less than substantial comment
I would assume this, but also
> is there some issue with the underlying empirical analysis of Rust’s library codebase?
this is hard to tell, because
> The paper, upon which the video is based is linked in the description and is easily accessed
I don't think this is true, or else, I am missing it somehow. Where is the paper? I don't see it linked from the page that's linked in the description, and a quick google of the title didn't turn it up for me either.
> The amount of time our industry wastes on C++isms is ridiculous where rust just works.
This implies that Rust doesn't have any problems, which is...crazy.
In addition to the problematic community, just rearchitecting your code to fit around the borrow checker can be a massive amount of work, which already makes it infeasible for use in some places where the primary work is not on greenfield projects but on legacy code.
> Unfortunately theres an old guard that refuses to let up and invest in rust.
...and this is just emotionally manipulative, in addition to incredibly dishonest about the problems that Rust actually has.
>> In 5/10 benchmarks, the benchmark games claims Go has equal if not better performance than Rust. Am I supposed to believe…
Believe that those Rust programs gave those measurements, and those Go programs gave those measurements (when compiled and measured as described on the website in tedious detail).
It does matter how the programs are written!
Write better Rust implementations for those tasks and contribute them --
> I’m all for playing with rust, but this post strikes me as engineers being distracted by shiny new things because they are only able to parse a TSV at 700kb/s?
They definitely just wanted to A.) Play with Rust, B.) Write a post about it.
This is the key line:
> As an intermediate Rustacean (I do have a fairly successful open-source project written in Rust, called fnm),
It's fine to say "I rewrote this code in Rust because I like Rust". We don't have to do a whole song and dance about why X needed a rewrite in Rust because X wasn't doing a good enough job. People do exactly this work in Node every day successfully. They just wanted to write Rust instead of optimizing some Javascript. _Which is fine_, just totally not newsworthy.
> that bugs in Rust code are physically impossible
This isn't a real thing either. I see it asserted all the time on HN and it's hilarious.
> Anyone hinting that bugs are still possible in Rust gets downvoted to oblivion (as here).
90% of the time it's because the person is making a stupid point. 10% of the time it's the community being annoying.
So just to reiterate, you're basing this on being barely an observer on forums, and I'm basing this on multiple years of professional rust development.
> there seems to be no use case for which Rust isn't good
You should read Why Not Rust (https://matklad.github.io/2020/09/20/why-not-rust.html). It was written by someone who has written a lost of Rust and likes the language, but acknowledges that it's not always the best tool.
It's a few years old, so not all of it holds up. For example, the author criticises the IDE tooling as immature. I don't think that's true in 2023. Coincidentally, the author created the official language server for Rust.
... What else would you expect? The author observed something, drew a mistaken conclusion, wrote it up, and then had the mistake pointed out, and so retracted. I can't imagine the author realised their claims were wrong before it was pointed out, so of course they're only going to cross them out after being corrected. Of course, it's rather unfortunate that an incorrect write-up is being upvoted to the top of HN but that's not the author's problem (other than the choice of the rather clickbaity title...).
For the specifics of this post, there's some subtle differences between how Rust and C++ behave that could easily explain how the author observed differing behaviour and thus jumped to the conclusion, as explored on /r/rust: https://www.reddit.com/r/rust/comments/63ijkw/rust_optimizat...
reply