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

[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.

[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.

[F.Ultra]

Yeah, it's in the standard since C99, but who uses it? It's incredible insecure, because the programmer has to say: "I promise here is no pointer aliasing". How often do you see the restrict keyword in function parameters? I have never seen them in the wild. So in theory C has the feature, but almost no one uses it, because if the condition is violated, you have undefined behaviour.

It has been in the standard since day one, however most compilers only implemented strict aliasing when C99 was in the works. Don't confuse this with the "restrict" keyword where you can declare pointers of the same type as not being allowed to alias. 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.

No the reason why these new coreutils in Rust is faster than the old ones in C is that they use new algorithms and that the old GNU utilities where written to run on systems with 4kb of RAM.

[soulsource]

Forcing programmers to initialize variables is not the same as forcing them to program correctly. It only forces them to assign values to their variables and it often ends being 0. The real problem is that when a programmer forgets to initialize a variable before using it, then it really means that he forgot what value it has by the time he is using it. It there matters little whether the variable was initialized with a 0, 1, has a random value, or is uninitialized.

That's why I mentioned that Rust is closer to functional programming languages. The term "variable" is actually a misnomer in that context, as in idiomatic Rust almost all values are immutable, and their final value is known at the point of declaration.
This is very similar to the concept known as "const correctness" in C/C++, with the main difference being that it's the default behaviour in Rust.

What does help is to warn programmers of uninitialized uses, because by some chance might they look at their code again and they might spot the problem, which can be a completely different one, i.e. a misspelled name such as using i instead of n. However, forcing programmers to always initialize their variables only removes the chance for them to get this warning. They will simply initialize all variables, and as a result, will the compiler throw fewer warnings and produce seemingly working code, but it may not actually work correctly and the programmer has no clue as to why.

The warning would only be shown if one of the values were not initialized. The equivalent situation in Rust (or const-correct C/C++) would be that one variable is not declared yet, and will also yield a compiler error.

[Siuoq]

Unless there is proof of GNU Coreutils actually being unsafe is the project a waste of time. It would be better to improve GNU Coreutils directly than to have yet another clone or fork of something with an unproven claim on it being supposedly safer without ever providing hard evidence.

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.)

[Volta]

Linux sucks.

Linux killed your POS OS? Good!

[sdack]

... it's far more common that one forgets to initialize a variable although one wanted to, than that one needs an uninitialized value. ...

Forcing programmers to initialize variables is not the same as forcing them to program correctly. It only forces them to assign values to their variables and it often ends being 0. The real problem is that when a programmer forgets to initialize a variable before using it, then it really means that he forgot what value it has by the time he is using it. It there matters little whether the variable was initialized with a 0, 1, has a random value, or is uninitialized.

What does help is to warn programmers of uninitialized uses, because by some chance might they look at their code again and they might spot the problem, which can be a completely different one, i.e. a misspelled name such as using i instead of n. However, forcing programmers to always initialize their variables only removes the chance for them to get this warning. They will simply initialize all variables, and as a result, will the compiler throw fewer warnings and produce seemingly working code, but it may not actually work correctly and the programmer has no clue as to why.

[wswartzendruber]

So Rust it is just the excuse to erase the GPL from the "GNU Coreutils" and to leave just "Coreutils". Genius!

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.

[soulsource]

At least some of this stuff is allowed because it was expected to interact directly with hardware in C programs. Volatile variables, for instance, can be set by some HW device instead of the program. You can also set variables or return values from inline assembly instead of C. This all made sense when you programmed your C64 in 1983 but is mostly obsolete in 2022.

It wasn't that reasonable back then either. It's not like Rust wouldn't allow you to leave variables uninitialized or to have the same behaviour as C's volatile keyword. It's just not the default, because it's far more common that one forgets to initialize a variable although one wanted to, than that one needs an uninitialized value.
There's another thing at play here, btw.: While Rust is a multi-paradigm language, it's much closer to functional syntax than C(++) is.

[Raka555]

At least some of this stuff is allowed because it was expected to interact directly with hardware in C programs. Volatile variables, for instance, can be set by some HW device instead of the program. You can also set variables or return values from inline assembly instead of C. This all made sense when you programmed your C64 in 1983 but is mostly obsolete in 2022.

Until you want to write something that runs on a micro controller or bare metal RPI (or similar device)
And we programmed our C64's in assembly back then, not C.