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

[sdack]

Well yes, but actually no. I think you can consider C codes as technical debt. There is no reason for a piece of code to be in C, it just causes it hard to maintain, change, debug, possibly risky, etc. Even if it's not a "debt" since there were no better option available when they first created Coreutils. "Rewrite It In Rust" is just the logical way of doing things. (Although. A rewrite will be more buggy for sure for a while, also easier modification will cause shorter lifespans, and compatibility issues.)

This may be your opinion, but just as you cannot go around and claim without proof that the GNU Coreutils were unsafe and therefore would require a rewrite in Rust, can you also not run off and claim a rewrite would be buggy when there is proof of the rewrite already working.

[krzyzowiec]

In this regard while Rust is as good as you are going to get when it comes to zero cost abstraction systems language it doesn't come close to Scala in terms of expressiveness for a strongly typed language.

Yes by "static" I meant an unmanaged language. The only way to have cleaner syntax is automated memory management like Scala/Kotlin/Clojure/JavaScript.

[Danielsan]

We *want* new Coreutils to be MIT licensed because we want as many people using them as possible. Hopefully, macOS does something with them.

Security wise, everyone is better off the more we can get the C programming language *off* of store shelves.

This is a prepacked answer...

[Steffo]

That said the benefits of restrict is mostly academic, the compiler does a code analysis already to determine of the pointers really do alias or not and for 99% of cases (or something around that number) the compiler makes the correct guess. I've never seen any benchmarks where restrict makes any difference outside of error bars.

99%? This is why we have the restrict keyword?! Right...
In the Rust community there are bug reports, because the compiler does not optimize correctly, because it assumes pointer aliasing. This is because the LLVM backend has bugs and the Rust developer disabled this feature temporary until the bug in LLVM is fixed.

[wswartzendruber]

This is a prepacked answer...

No. It is not. I came up with it myself. Perhaps a similar answer is available as some kind of talking point.

In any event, whether it is prepacked or not is irrelevant. It is still a compelling argument.

[Danielsan]

No. It is not. I came up with it myself. Perhaps a similar answer is available as some kind of talking point.

In any event, whether it is prepacked or not is irrelevant. It is still a compelling argument.

Which operative system is prevented to use a GPL software if the GPL is respected?

From the Debian wiki:

The GNU Core Utilities are the basic file, shell, and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system.

Do we finally solved the GNU/Linux dilemma?

[wswartzendruber]

Not all operating systems respect the GPL, obviously.

macOS certainly doesn't. The BSD variants don't. The FSF and GPL are not the end-all, be-all of software licensing. Regardless of what they say, Apple will still be proprietary. And their products will continue to fill store shelves. And consumers will continue to not care.

[Danielsan]

Not all operating systems respect the GPL, obviously.

macOS certainly doesn't. The BSD variants don't. The FSF and GPL are not the end-all, be-all of software licensing. Regardless of what they say, Apple will still be proprietary. And their products will continue to fill store shelves. And consumers will continue to not care.

You said the MIT license would allow more involvement or adoption...

we want as many people using them as possible

But these are very basic commands from which you don't build any modern "stacks":

this package includes: arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false flock fmt fold groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes

The only point here is to erase the word GNU...

[wswartzendruber]

The point is to get rid of the GPL.

[F.Ultra]

99%? This is why we have the restrict keyword?! Right...
In the Rust community there are bug reports, because the compiler does not optimize correctly, because it assumes pointer aliasing. This is because the LLVM backend has bugs and the Rust developer disabled this feature temporary until the bug in LLVM is fixed.

I have no experience with LLVM, I use gcc exclusively and have yet to see any real practical benefits from "restrict" but if you have any benchmarks to share I would be delighted, I use restrict whenever I can just in case but as I wrote earlier it have so far not made any major difference for me (and I work with extreme low latency software in the financial industry) so either I happen to write code that is very easy for gcc to correctly profile or this is one area where gcc happen to be better than LLVM.

And do note that we got the keyword due to the C99 committee thinking that it would be a good idea, I don't think any one provided hard numbers to back it up back then, at least none that I could find. And pointers of different types where already strict non aliasing in C before that by default, restrict is just to add it to pointers of the same type.

edit: Here is an often cited paper that shows a less than 1% speed-up on average from using restrict http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf

edit2: What we would really need in C is to have function declarations declare that const really means const. What I mean with this is that there is no way to inform the caller that memcpy (void *dst, const void * const src, size_t n ); will really not write to *src since a const pointer can be overridden by a cast at any time (meaning that the memcpy function can cast away the const inside it). GCC have a really clunky "
__attribute__ ((access (read_only, 2, 3))) void* memcpy (void*, const void*, size_t);" but it would be much nicer to have a real type qualifier like restrict here, or rather a "I promise that my function will obey const" qualifier.