Rust-Written Replacement To GNU Coreutils Progressing, Some Binaries Now Faster

[poncho524]

1. Ada never caught on outside of very specialised use cases because its compilers were expensive and required expensive hardware. Had Ada been free (as in both beer and speech) and ran on the typical personal computer at the time, it may have become more popular but now that ship has long sailed. Like Plan9 and VMS have always had some features that are only now coming to Linux, but the point is that people want to use Linux, no-one is going to go back to those OSes.

Ada does have free compilers. It's part of GCC.

[jacob]

Ada does have free compilers. It's part of GCC.

It does now, but it came too late. Ada's window of opportunity was in the 1980s. By the time GNAT arrived, C++ had already taken the spot. It was inferior in virtually every way, but it was cheap, accessible and available.

[LuukD]

..
- Rust's built-in data structures (e.g. their Has map) tend to be pretty well optimized compared to the average basic C implementation

I have to object here. Std library's HashMap implementation is not known for being very fast (the std library team chose safety over speed - so a hash collision free algorithm is used.). There are plenty of crates providing much faster algorithms but these do not provide the same guarantees.

Take a look at Nicolas' blog post to learn a bit more on the topic.

[zcansi]

I have to object here. Std library's HashMap implementation is not known for being very fast (the std library team chose safety over speed - so a hash collision free algorithm is used.). There are plenty of crates providing much faster algorithms but these do not provide the same guarantees.

Take a look at Nicolas' blog post to learn a bit more on the topic.

The default hash function is costly to prevent hash collision attacks, but the hash function is a generic parameter which can be overridden. Thus it's perfectly possible to use the standard library's hash map with excellent performance (as it is indeed very highly optimized).

I do think Rust's performance advantage is mainly because the Rust ecosystem is so much nicer. Because it has a much richer type system you can make much nicer library APIs, and because it's so much easier to integrate dependencies it's also much nicer to use those libraries. A lot of the functionality being built for these tools is being made available to the Rust ecosystem in the form of libraries, for example the functionality for reading/setting SELinux filesystem data, so it benefits even those who don't use the CLI tools.

Kind of disappointing to see people complaining about the licensing. This isn't some anti-GNU conspiracy and it's not even about safety, I think most people are just working on this because they want a small Rust project to work on and making small CLI utilities like this is a perfect scope for some hobby programming. MIT/Apache2 is the standard licensing in the Rust ecosystem, and in Rust as I said it really pays off if you integrate easily with the rest of the ecosystem. No surprise they chose MIT.

[poncho524]

It does now, but it came too late. Ada's window of opportunity was in the 1980s. By the time GNAT arrived, C++ had already taken the spot. It was inferior in virtually every way, but it was cheap, accessible and available.

Not later than rust.

[LuukD]

ripgrep is not comparable to these other tools. ripgrep is multi-threaded while these other tools are not. If you use grep with something like gnu parallel it will run as fast or faster than ripgrep. I have used grep in single large files at work and grep is simply much faster.

I agree on the intrinsics. That is just foul play isn't it?

But parallelism is just awesome in Rust. The language just makes it too convenient not to use it. Computers have many cores these days, better to make use of them if we can. Instead of using 'find' I use ripgrep - it is so much faster.

C is absolutely cool and fast and I do not think Rust is 'faster' per-se. Some times it is, some times it isn't. As always, it depends. But Rust does make some pretty cool guarantees C/C++ cannot. Like being data-race free!

[LuukD]

Kind of disappointing to see people complaining about the licensing. This isn't some anti-GNU conspiracy and it's not even about safety, I think most people are just working on this because they want a small Rust project to work on and making small CLI utilities like this is a perfect scope for some hobby programming. MIT/Apache2 is the standard licensing in the Rust ecosystem, and in Rust as I said it really pays off if you integrate easily with the rest of the ecosystem. No surprise they chose MIT.

Exactly.
I find it really weird to see OSS enthousiasts make such a fuss over software being released with a permissive license. Everyone can use it, so can they. The MIT style licenses are chosen to increase adoption and I think it paid off. If the license had been restrictive, I do not think Rust would have had the backing and support it has today.

[SvenK]

I'm wondering if mesa would benefit of a rewrite in Rust or in using Rust in the future.

[jacob]

Not later than rust.

It is later than rust. Every language has a window of opportunity during which it must prove that it actually solves a pressing and current problem, in a practical and usable way. If it's not practically usable at the right time, the world moves on and even if the language removes its initial blockers at a later time, it's basically game over. No-one is going to give it another look. We could say the same thing happened to dlang, which is objectively overcoming many (not all) of its former hurdles but its launch window has long passed. It's unfair, perhaps, but that's how it works in the world. Maybe the only exception to this rule is Python, who became mainstream and widely adopted more 20 years after it first appeared. I believe it's probably because the demand for what it offers really only materialised after 2010 or so, and so its Right Language At The Right Time moment suddenly come about. But I don't know what it would take for Ada to take off in the same way. It's surely better than C++ but the point is, we already have Rust for that and it's already more widespread with a better ecosystem than Ada ever was.

[re:fi.64]

I have to object here. Std library's HashMap implementation is not known for being very fast (the std library team chose safety over speed - so a hash collision free algorithm is used.).

This is true to an extent, but I was comparing it to the average C re-implementation. IOW, it's hard for me to imagine Rust's swiss tables aren't at least a bit faster than gnulib's, which I'm pretty sure just uses closed addressing and linked lists of buckets.