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

[ZuseZ4]

I'm not sure if I understand the GPL thing. Ok, if you don't want to freely share your code, but didn't you already lost at the time where the Rust Apache2/MIT version catches up? Nobody previously limited by your GPL license will care anymore, as they just have the Rust version with the same features, due to which it doesn't matter anymore which license you have?

[amxfonseca]

the fact that it use an MIT license instead of GPL makes it automatically a regression - any performance gains etc don't matter

If you're putting the effort to make the codebase simpler and more readable, why not doing the same with the licence file...

[dec05eba]

https://benchmarksgame-team.pages.de...ust-clang.html

Just look at the first example. Rust in the first example uses manual SIMD intrinsics while the C version does not use any SIMD. It's like writing assembly and saying its rust.

People writing highly optimized Rust versions of important tools we use everyday that are much faster than the originals is already a thing.

https://github.com/BurntSushi/ripgrep

Lots of benchmarks: https://blog.burntsushi.net/ripgrep/

There are a bunch of other Rust versions of essential tools that are worth looking into. Some offer far better performance, some offer more intuitive syntax, some offer a bunch of nice new features, or some mix thereof.

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.

[Developer12]

People rushing to defend the pile-of-shit language known as C will never cease to amaze to me.

Unless you manually enable unsafe mode, Rust doesn't permit direct memory access and that's that. Get over it.

The sooner C utilities are replaced with Rust utilities, the better off we'll all be. Hell, I just got done having to drop everything and update my Debian machines because you can corrupt PolicyKit to get root access.

What a stupid, pathetic excuse for a systems language.

People forget that C was made in the heat of the moment. There are lists of standard functions that are still supported but must never EVER be used ie. ones that write to a caller-supplied buffer but accept no size argument. A surprising amount of the C standard lib is broken on a semantic level.

While you can patch around some things with replacement functions, you really can't fix the core language stuff. We just develop an ever-growing list of mistakes and hope everyone applies that *entire* checklist to every line of code they write. That's what makes a "good C programmer." Linters would be great but have a hard time because this ah-hoc language has so much ambiguity.

Rust does away with all of this by restructuring the language to be more specific. Type system, borrow checking rules, etc. Then the compiler actually CAN understand exactly what's going on, apply all these rules at compile-time without an ocean of false positives, and find more places to cut out instructions while still being safe (unlike the infamous -O3).

Bottom line: C endures because it's an ugly hack that was just good enough, in the right place at the right time. Not because of any good properties that are still unique. We can do better now, replace it.

[sdack]

Rust doesn't permit direct memory access and that's that.

When it is this easy to prevent mistakes from happening then we should not allow people to make mistakes in the first place, and we get 100% bug-free code.

[MadCatX]

That you want to think of it as hypothetical is your fault. A lot of higher-level languages prevent you from making mistakes one can only do in C. Rust just is not doing much in comparison that warrants its use. Nor are there such classes of mistakes as "easy" or "very easy". It remains a matter of skill and experience. No language will make you into a better programmer when the reason for your mistake is a lack of knowledge, ignorance, laziness, or stupidity. Forcing people to program in a specific way has about as good a chance in making them even lazier as in making them more diligent. I am sure you know what I mean, don't you?

How much real world programming experience do you have? The software we write today is so complex that keeping track of everything in your head is just impossible. It is very easy for a code that used to be correct to suddenly break because some subsystem changed in some way that had unexpected consequences. The only way out of this is to use tools that detect problems in advance. If you look up the reasons behind the most severe security issues reported in the last 10 years, I can assure you that unbounded memory access, race conditions and resource mismanagement will be on the top of the list. Rust is designed to prevent these and it does so very well. I don't understand your need to argue with facts that you can easily check. Sure, it's not a silver bullet but nobody has ever claimed that.

Nor are there such classes of mistakes as "easy" or "very easy".

Yes, there are. It is very easy to mistakenly use <= instead of < or forget a nullptr check. I guess that the guy who wrote software for the infamous Therac-25 wished he had Rust back in the day.

[sdack]

People forget that C was made in the heat of the moment.

We had many standards after K&R, not to mention C++, and none of them being "heat of the moment". Any programmer, who does not know the risk of using gets(), will be just as bad a programmer regardless of the language they use. The language that stops people from making mistakes has not been invented yet despite all claims of Rust being a magic bullet.

[poncho524]

I'd people dig the safety that rust offers, why not use Ada?
why is rust talked about like it's revolutionary when Ada has had these features for forever?

[sdack]

Yes, there are.

No, I am talking objectively. What is "easy" or "very easy" is a matter of subjectivity. The very idea that a language could prevent you from using < instead of <= because it was an "easy" mistake to make is madness. Not checking for a NULL pointer is often laziness, sometimes also caused by a lack of attention, but it can have many more reasons. The problem is not the lack of the check but the human nature that led to the mistake, and as long as the guy at the keyboard does not get his shit together does it matter little what language he uses. And as long as this is the case will you use the wrong register in assembly, place your test at the wrong scope in C, initialize your objects in the wrong order in C++, or perhaps even use the wrong language altogether. You will keep making mistakes and these will need fixing. To think Rust would change this and lead you to make fewer mistakes is a pipe dream.

[poncho524]

Since C has the phrase "undefined behavior" written all over its specification, *proving* that a C program is really safe might be the difficult task, actually.

C doesn't have "undefined behavior", libraries do.