231–240 of 546 posts
I'm a Rust evangelist, but the article is titled "Speed of Rust vs. C" and doesn't seem to contain even one benchmark. For fuck's sake.
I completely agree with the points made here, it matches my experience as a C coder who went all-in on Rust. >"Clever" memory use is frowned upon in Rust. In C, anything goes. For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED). Ha! >It's convenient to have fixed-size buffers for variable-size data (e.g. PATH_MAX) to avoid (re)alloca…
Earlier quoted context omitted.
But that may be of little solace. If you snapshot your entire heap into an mmapped file for fast I/O, then basically the entire advantage of Rust is gone.
> If you snapshot your entire heap into an mmapped file for fast I/O, I've never heard of this trick. And my first reaction is "That would be a nightmare of memory unsafety if I did it in C++" What's it used for? IPC?
Shouldn’t this be Rust vs C++? C++ has a lot more parallels to Rust. Both are big, complex, and safe languages that can tuned for high performance. Infact, I would like to see more comparisons of Rust and C++ in the future.
Very biased comparison without actual source or numbers to back things Even more surprising it got to front page Do people really have low standard of quality on hacker news too?
Earlier quoted context omitted.
> In embedded applications you don't usually have the possibility to have parallel code, and even in low level software (for example the classical UNIX utilities), for simplicity and solidity using a single thread is really fine. Depends on which of the classic utilities you are talking about. Many of them are typically IO bound. You might not get much out of throwing more CPU at them.
ripgrep? :)
I would guess it contains more c than rust code...
But what I love about this article is its lack of hype. It makes clear arguments both ways and all of them I can get behind
Hype doesn't help
Edit: To all my downvoters; I anticipated you :) With love and best wishes
I completely agree with the points made here, it matches my experience as a C coder who went all-in on Rust. >"Clever" memory use is frowned upon in Rust. In C, anything goes. For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED). Ha! >It's convenient to have fixed-size buffers for variable-size data (e.g. PATH_MAX) to avoid (re)alloca…
Earlier quoted context omitted.
But Rust works badly with mmapped (memory-mapped) files, as the article notes. So in C you could load (and save!) stuff almost instantly, whereas in Rust you still have to de-serialize the input stream.
It doesn’t say it “works badly” it says the borrow checker can’t protect against external modifications to the file while memory-mapped, which has a host of issues in C as well. You can mmap files in Rust just fine, but it’s generally as dangerous as it is in C.
Earlier quoted context omitted.
But Rust works badly with mmapped (memory-mapped) files, as the article notes. So in C you could load (and save!) stuff almost instantly, whereas in Rust you still have to de-serialize the input stream.
No you don't. I've written multiple programs that load things instantly off the file system via memory maps. See the fst crate[1], for example, which is designed to work with memory maps. imdb-rename[2] is a program I wrote that builds a simple IR index on your file system that can then instantly search it by virtue of memory maps. Rust "works badly with memory mapped files" doesn't mean, "Rust can't use memory mappe…