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

[caligula]

There is no single reason why C is faster. Everything which is possible in C, is possible in Rust. But the other way around is not true. In fact, Rust guarantees strict aliasing, such that the compiler can optimize more aggressively than ever possible in C.

C programmers often argue that every sequence of instructions can be implemented in C, thanks to inline asm.

[sdack]

How do manufacturing and environmental factors apply to programming languages? This is supposed to be an analogy, remember?

No. These are not analogies, but examples of simplicity. It is because of simplicity that C is still going strong and has outlived more complex languages. It is just more sad that you do not see this even when one compares C to a hammer.

[Steffo]

C programmers often argue that every sequence of instructions can be implemented in C, thanks to inline asm.

Inline assembly is a really, really rare corner case. Even in OS development. But Rust does also support this, but the feature is not stable yet. Which is more often used are SIMD instructions, which is well supported by stable rust.

[Rallos Zek]

Might be more interesting if it was not released under a anti-freedom cuckold license.

[clavko]

Right. I've been working for years in embedded (pure C), then working on super complex, millions of lines C++ with CRTP/SFINAE etc and now I'm in Rust. Rust is SUPER productive, removing possibility of stupid bugs I've seen people with high IQs and PhD's do (no immunity), and with arguably best build, test and dependency management of the lot. It's incredible how much faster and safer development with Rust is for majority of things one would use C++ for. No IT powerhouse is able to ignore it, and they're hiring hundreds of developers for new Rust projects. Linus and GKH have allowed it, and that in itself is a huge vote of confidence. This C lover guy is talking a bunch of nonsense, and no one should pay attention to him one bit.

[JustRob]

From the link, "Elixir leverages the Erlang VM". The use of VM blocks a lot of stuff. Any language that use VM can only be trusted, before careful investigation, to replace projects that already use VM / interpreter. So Elixir may replace Java or Python, but definitely not anything of C. The resistance will be so high that nobody bothers.

The projects AXD301, the Bluetail Mail Robustifier and the Alteon SSL accelerator are all large projects, award winning and proving great trust. That is well studied, long ago.

[wagner17]

Coreutils mainly contains utilities used in bash scripts. Half of the tools are simple command line utilies that don't need to perform that fast and have no use outside bash scripts. E.g. commands like [, true, false, nproc, echo.. FWIW, the GNU versions of true and false are probably among the slowest ever invented since they have all sorts of i18n gettext dependencies while a simple implementation would just return a single value.

Is that because of coreutils or the Linux i18n patch that has been applied since 2001 by Linux distros to add i18n support to coreutils? The patch has had performance issues (see https://bugzilla.redhat.com/show_bug.cgi?id=499220).

[Volta]

Hopefully this mit licensed crap won't be picked by Linux distributions.

[billyswong]

The projects AXD301, the Bluetail Mail Robustifier and the Alteon SSL accelerator are all large projects, award winning and proving great trust. That is well studied, long ago.

Tools that are excellent for large projects and long uptime doesn't automatically translate to excellence in implementing small programs that are short-lived. The current Rust alternative of coreutils are already facing question of binaries being too "big" and planning to find out how to reduce them. Loading a VM every time coreutils are used or keeping a VM running behind will cause even greater resistance.

Software projects that are suitable running in VM or interpreters have already moved to utilize them over the last few decades. The remaining projects that stay in C don't stay because they don't know some languages running in VM can be very productive. They stay either because the platform support of those VM aren't broad enough, or because they require / like their projects to be coded in a more close-to-metal way. VM and interpreters contain startup overhead that can never be totally eliminated.

Sometimes, it is just that your favourite pet language is not popular enough. So there is not enough open source manpower to be attracted to join. Rust is a lot more popular, with a lot more people gained experience with it, and earned a lot more trust in FOSS community. Since Rust has already gained traction and being advertised as a all-rounder to supersede the job of C, any other programming languages cannot succeed in replacing C just because they are a lot better than C. They have to show themselves a lot better than both Rust and C.

[pabloski]

someone starts a new project today with tools less than state of the art

The point made by the anti-Rust crowd is that Rust isn't state of the art and doesn't prevent some classes of bugs. Their arguments to support such nonsense are bogus at best.

This is the real problem. Non programmers ( or hobby programmers that write hundreds of lines of code at max ), certainly people who have never ever used Rust or at least read the first chapters of a good book like Programming Rust by Orendorf et al. Because otherwise it is impossible to understand why they write such patently falsehoods about the language.

Some even define Rust a mess and point to the non-existence of a GNU compiler as proof of the inferiority of the language. Plainly absurd. And it needs a jump here to see that it is a bogus argument https://github.com/rust-lang/rust