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

[jacob]

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

Because the GPL maintains the system fair - everyone who wishes to use your code must keep it open source. MIT, BSD and similar licences simply give a free ride to closed source proprietary developers with absolutely nothing in return. No wonder Apple and Microsoft love them and detest the GPL.

[Turbine]

I will need to see benchmarks of any language being faster than C that is not named machine code or assembly. I find it VERY hard to believe that any Rust language program can beat a pure C language program. I have some friends that are die hard Rust fans and I don't see the point in learning it when I already know C and C++. Throw in a bit of shell scripting, Perl Scripting, and good old C and you can write an entire OS!

I think there's a few things you need to consider. I can write complex things in JavaScript in a day which would take me a possibly a month or more in C++. I think Rust is attractive because it's easier to maintain, can write nicer code and can detect errors (which you haven't programmed to catch) and print them out for debugging.

I'm not into Rust, but I know enough about it to find it extremely appealing.

[oleid]

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.

Then pick a different implementation of the first example. There are a few non simd-versions faster than the fastest c implementation:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html

By the way, the fastest implementation is a simd-c++ version. But like you said, that's no c++.

[JustRob]

There's support for rusting things but I wonder why Elixir wasn't chosen: https://elixir-lang.org/

There's already a GoLang version: https://github.com/guonaihong/coreutils

The rewrite was a solution searching for a problem we didn't have while avoiding a better suited (for CoreUtils) language that scaled and is concurrent, with safety.

[brad0]

C doesn't have "undefined behavior"

What? "UBsan uses compile-time instrumentation to catch undefined behavior (UB). Compiler inserts code that perform certain kinds of checks before operations that may cause UB."

[jacob]

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?

1. Rust doesn't have the same features as Ada. Ada is richer than Rust when it comes to runtime checks, with its interval types etc., but Rust goes much further in static analysis than Ada with its borrow checking and lifetime analysis. It also has some nice bonus features that don't exist in Ada, like the Hindley-Milner type inference
2. 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.
3. Rust has much better runtime performance than Ada

[jacob]

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

Ha ha ha. And you know the one about the Irishman and the Scotsman who go to a pub?

[oleid]

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

Good one!

https://blog.regehr.org/archives/213

[MadCatX]

We had many standards after K&R, not to mention C++, and none of them being "heat of the moment".

K&R was never a real standard, C89 was. C99 added a bit of syntactic goodies to help with readability and performance here and there but nothing really groundbreaking, C11 has a few features to deal with multithreading and memory alignment. Useful but not really exciting. C++ made a much bigger leap with C++11 compared to C++03. Whether that leap was a leap in the right direction is another question but at least they tried. Admit it, you don't really know what you're talking about, do you?

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

C does have undefined behavior. That's one of the reasons why it's so portable. Compile this snippet with "-fsanitize=undefined" and observe

#include <limits.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
int i = INT_MAX;
printf("Only God knows what this does %d\n", ++i);

return 0;
}

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.

For one last time: People make mistakes. We have known that for a very long time. We have also learned that some mistakes cannot be prevented simply by fixing the human. That's why we replace humans with machines in areas where mistakes are likely to happen and costly do deal with. It doesn't matter how good somebody is, everybody messes up once in a while. The proper way to deal with that is to have protocols and tools that detect a problem before it becomes a real problem.

[coder]

Not really. When an increase in complexity brings fewer gains then the logical conclusion is to go with simplicity.

Not sure if you read my whole post, but I think there's good evidence that C lacks all the expressiveness programmers need (and compilers want). So, they used various escape-routes, like type-punning. Rather than having a language that's deficient for its intended task, a more expressive language could probably improve the simplicity of programs, and reduce the learning curve for programmers, as well as enabling compilers to generate better code.

Basically, the simpler the tool, the more burden you place on its users. Hence, there's an optimal amount of complexity. And even if C was the best low-level language of its era, that doesn't necessarily mean it's optimal for any purpose, today.

As such have inventions like the wheel, the blade and the hammer remained for a long time and are still widely used today.

It's funny that you pick on those examples, because basically every wheel, knife, saw, and even hammer is now made of different materials and in different ways than they were even 100 years ago.

The other weird thing about this analogy is that there's a vast diversity of these tools to suit different purposes and needs. That's because they don't scale. If you need to drive a big stake into the ground, you don't use the same hammer as you'd use to nail floorboards. Anyway, we can spend a lot of time arguing over your analogy, but I think it's telling that you didn't address the more substantive points I made.