Note GNU coreutils has a good test suite which just calls out to the various tools from shell and perl scripts. It should be easy enough to run this implementation through it.
More effort goes into the coreutils tests than the code.
One of the hardest parts of coreutils is keeping it working everywhere, including handling that buggy version of function X in libc Y on distro Z. That's handled for GNU coreutils by gnulib, which currently has nearly 10K files, and so is a significant project in itself.
Actually that makes me think this project may be very useful. If gnulib is that needed for compatibility, then rust-coreutils should be a great test-case of system compatibility for rust itself. It could uncover many things that should be done inside rust rather than this coreutils implementation.
Curious to the benefits of this. Is Rust performant and on par with the native C version of coreutils? Seems the readme makes a big deal about being easy to compile on windows (which has never been a problem for me, I just use Cygwin or something).
Also, comments like this make it seem this is not "fully baked" yet and still needs some dev time:
> fn parse_date(str: &str) -> u64 {
> // This isn't actually compatible with GNU touch, but there doesn't seem to
> // be any simple specification for what format this parameter allows and I'm
I was already secretly imagining a future where Rust will completely replace C as the low level language for everything. Even the Linux kernel rewritten in it eventually. It'd be a much better world with no #ifdefs, strong type safety and memory safety depending on compilers instead of fallible programmers.
But I was expecting it would take a while before people had the ambition to start doing these things, even when it comes to the smaller ambition of rewriting the GNU coreutils. Rust is a great language already, but it's not a stable language yet.
I wonder if my imagination will become reality eventually. There's really good buzz around Rust now, and it's not even 'production ready'.
The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages. Also, C is extensively standardised, widely used and thus greatly test-covered. This is a nice property of the language, as the programmers can be sure that as long as they follow the standards, they'll find a compiler to compile the programs they write. I have not used Rust for more that «Hello world!», but I know that I'd regret sooner or later, if I wrote a multi-million line project in a language that is not somehow standardised.
Also, memory safety is hard to enforce, I reckon, while controlling the memory hardware, which is what an operating system like Linux* has to do. Rust can be used, but still, there are many unsafe things that OS has to do, like moving and assigning pages, managing which programs use which pages, swapping, etc.; which, I reckon, requires knowledge and usage of physical memory addresses and access to individual bytes.
Rust may be an appropriate and advantageous language to use for the non-core parts of a microkernel, though.
* I acknowledge that Linux is not an operating system per se.
I hope that never happens, because I think such a world would be extremely dystopian. Strong safety guarantees sound very beneficial at first ("safe" anything in general tends to evoke that response), but as shocking as it may seem, a lot of the freedom we have today is a result of using "unsafe" languages like C: iOS jailbreaks, Android rooting, homebrew on game consoles, and many other examples of freeing one's devices from restrictions imposed by the original manufacturer and giving control back to the user depend on this. These bugs and vulnerabilities, although they can be exploited maliciously, are in some ways like an escape hatch from the tyranny of corporate control. If strongly safe languages become the norm, all these would disappear and our computing experience become even more locked-down and restricted. The thought of them being used for DRM is scary (I remember reading an academic paper that suggeted this as one of their applications, and that's one of the thing that provoked me into really starting to think about this.) Even open-source software where safer languages appear most beneficial can be used against the user.
Ultimately is a security vs. freedom tradeoff, and I think we've sacrificed too much of the latter already.
I don't think it makes sense to rewrite the Linux kernel in Rust. As long as we're dreaming, let's talk about a new OS without all the legacy cruft. Be sure to make it hard to lock the user out, so userbinator is happy too, but (again) as long as we're dreaming that's on the agenda too.
"uutils is licensed under the MIT License - see the LICENSE file for details" - funny to see GNU software reimplemented in another open source license.
I do not understand the down votes. Can somebody explain?
I did not mean to hurt any feeling. I was just surprised to see the license of a software where "GNU" is in the title. I naturally assumed that it will be in GNU license. So it was a surprise to discover MIT.
Now I understand. I should have written "surprising" instead of "funny". Sometimes writing about a subject gives you the answer.
Free software reimplementation projects go to great pains to avoid code written by people who have looked at proprietary source. I hope this rewrite extends the same courtesy.
How stable and usable is Rust's ABI? Can I easily call Rust code from C or other languages that can easily call C functions? I ask because I think this is one area in which C++ has really failed. C++ is a bad language for building frameworks and libraries for consumption from other languages because interfacing with C++ code is such a nightmare. I'd hope any language that aspires to displace C++ has a better story here.
> However, [other ports of coreutils to Windows] are either old, abandoned, hosted on CVS, written in platform-specific C, etc.
I don't get how on the earth can using CVS for version control be an appropriate reason to consider a software project bad. Yes, CVS is old and centralised, but, is it that big of a deal that it's usage by a project per se projects the project old and inactive?
This looks like it's handy for learning purposes, but is there actually any practical use for this? I don't think that the code size and the pace of development really require changing the core language.
Past re-implementations have focused either on the learning experience, code size (for embedding or Unix "purity" reasons) or the license (i.e. not GPL).
Most of these tools are small enough and simple enough that they sort of "get finished." Probably not interesting but to some purists.
There is something to be said for the nice clean implementations of some of these tools. There is a little to be said for the language itself.
Really, something bigger and better is needed. A new HTTP server, a new sendmail or something, a new DNS server. I'd love to see Go or Rust take on Bind and produce a safe, secure, high performance implementation. The Ada guys never stepped up and produced anything interesting to show their tools' superiority, there is a lot more interest and community in Rust and Go. What's the leakiest, buggiest part of the equation right now? Go make a better one.
Nice. However, I feel there're two things really needed to be done here: move all that cat|du|... to some src|source|whatever directory and add 'tests' directory with somewhat more robust tests layout than the current one. It would be really cool to replace (seriously, just for the arts sake) coreutils with this one, but I wouldn't dare to do it if I'm unable to easily verify that they both work and work at least almost as fast as coreutils on my platform. It's important stuff, you know, otherwise it wouldn't be called "coreutils", really…
It will be interesting when they get down the to-do list to fmt, which contains the Knuth-Plass paragraph reflow algorithm -- the only C-language version I've been able to find, and about the only readable one, after Knuth's "literate" one.
Go is sort of a cross between Python and C with a bunch of concurrency support and a fairly elegant design. It's small and low cognitive overhead, but at the expense of certain types of expressiveness. It requires it's garbage collector, so it's hard to use it too far down the stack. It's gotten the most traction as a Python replacement, though I'd be happy to see it replacing Java in some cases too.
Rust is sort of like a cross between C++ and Haskell. It has better facilities for abstraction and enforced safety than Go, but at the cost of more cognitive overhead and being harder to learn. People who plan to use it generally use C++ now.
These languages are actually going after different use cases, and for my robot there are some parts of the codebase I'd write in Go if we were re-writing, and some in Rust.
Rust has a far better type system than go, and does not use a garbage collector, instead using its own idea of "variable ownership" to protect against freeing memory prematurely.
On the other hand, it's also in version 0.10, keeps changing all the time, and the stdlib doesn't contain nearly everything that Go's does, by design.
Whilst there is some crossover, The two languages occupy different niches, and have quite different philosophies driving their design.
Rust is far more extensible than Go - for example all of the concurrency primitives are built as libraries, and users can create their own depending on their unique use cases. Go's on the other hand are built in, and are difficult to extend.
Rust aims for generic, zero cost abstractions and control over allocation without compromising on safety, but this means the type system is more complex than Go's. Go's static type system is quite simple, and easy to learn, but is hard to write generic abstractions over unless you want to resort to using `interface {}`. Go also uses a mandatory GC which makes low level programming and interfacing with C difficult, but abstracts away from up-front memory management.
Rust's compiler is slow, but generates very fast code because it performs a great deal of static optimizations via LLVM. Go on the other hand builds blazingly fast but performs little to no optimization at compile time, nor compensates for that with a JIT.
If you want raw performance, control over allocation, and an expressive type system, choose Rust. If you want simplicity without having to think about allocation, choose Go.
Many GNU, Linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to Windows. However, those projects are either old, abandoned, hosted on CVS, written in platform-specific C, etc.
Rust provides a good, platform-agnostic way of writing systems utils that are easy to compile anywhere, and this is as good a way as any to try and learn it.
Well rust doesn't have garbage collection, its designed to replace* the languages that coreutils are currently written in - C (I don't think any gnu coreutils are written in C++). Go is not designed to replace these languages.
*by replace I mean occupy some of their current marketshare.
Because it's fun. I don't think there is a very strong reason for preferring Rust over Go except than the authors like it more. Hackers don't need to justify their decisions. They do stuff for fun and sometimes they end up with useful things.
Go produces fat binaries, probably not what you expect from this tiny tools. I even believe some linux distributions forbid packages that don't use shared libraries.
From what I've seen, the by far biggest thing that Rust and Go have in common is that when one of them mentioned on HN, the other is very likely to be mentioned, too. Beyond that, I don't see much similarity.
It's not really cross platform - whoami for example depends on libc which afaik isn't native on Windows.
I wrote one of the first utilities for this when it was first opened up for collaboration, so I hope it succeeds :) I need to go back and write tests for my util.
[+] [-] pixelbeat|11 years ago|reply
One of the hardest parts of coreutils is keeping it working everywhere, including handling that buggy version of function X in libc Y on distro Z. That's handled for GNU coreutils by gnulib, which currently has nearly 10K files, and so is a significant project in itself.
Some stats:
coreutils files, lines, commits: 1072, 239474, 27924
gnulib files, lines, commits: 9274, 302513, 17476
[+] [-] viraptor|11 years ago|reply
[+] [-] 3JPLW|11 years ago|reply
[+] [-] Alupis|11 years ago|reply
Also, comments like this make it seem this is not "fully baked" yet and still needs some dev time:
> fn parse_date(str: &str) -> u64 {
> // This isn't actually compatible with GNU touch, but there doesn't seem to
> // be any simple specification for what format this parameter allows and I'm
> // not about to implement GNU parse_datetime.
> // http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plai...
[+] [-] DCKing|11 years ago|reply
But I was expecting it would take a while before people had the ambition to start doing these things, even when it comes to the smaller ambition of rewriting the GNU coreutils. Rust is a great language already, but it's not a stable language yet.
I wonder if my imagination will become reality eventually. There's really good buzz around Rust now, and it's not even 'production ready'.
[+] [-] gkya|11 years ago|reply
Also, memory safety is hard to enforce, I reckon, while controlling the memory hardware, which is what an operating system like Linux* has to do. Rust can be used, but still, there are many unsafe things that OS has to do, like moving and assigning pages, managing which programs use which pages, swapping, etc.; which, I reckon, requires knowledge and usage of physical memory addresses and access to individual bytes.
Rust may be an appropriate and advantageous language to use for the non-core parts of a microkernel, though.
* I acknowledge that Linux is not an operating system per se.
[+] [-] nly|11 years ago|reply
And I happen to like having a preprocessor.
[+] [-] userbinator|11 years ago|reply
Ultimately is a security vs. freedom tradeoff, and I think we've sacrificed too much of the latter already.
[+] [-] andrewflnr|11 years ago|reply
[+] [-] Dewie|11 years ago|reply
[+] [-] reirob|11 years ago|reply
[+] [-] reirob|11 years ago|reply
I did not mean to hurt any feeling. I was just surprised to see the license of a software where "GNU" is in the title. I naturally assumed that it will be in GNU license. So it was a surprise to discover MIT.
Now I understand. I should have written "surprising" instead of "funny". Sometimes writing about a subject gives you the answer.
Sorry for those that I hurt.
[+] [-] pjc50|11 years ago|reply
[+] [-] endgame|11 years ago|reply
[+] [-] u124556|11 years ago|reply
[+] [-] cageface|11 years ago|reply
[+] [-] dbaupp|11 years ago|reply
However, you can easily define a function with a C ABI (and a non-mangled symbol name):
I'm not sure if you regard this as better than C++'s situation.[+] [-] reubenmorais|11 years ago|reply
Considering how quickly C++ compilers are iterating, it might even be available in GCC/Clang before Rust 1.0.
[+] [-] loudmax|11 years ago|reply
[+] [-] gkya|11 years ago|reply
I don't get how on the earth can using CVS for version control be an appropriate reason to consider a software project bad. Yes, CVS is old and centralised, but, is it that big of a deal that it's usage by a project per se projects the project old and inactive?
[+] [-] mhd|11 years ago|reply
Past re-implementations have focused either on the learning experience, code size (for embedding or Unix "purity" reasons) or the license (i.e. not GPL).
[+] [-] Nelson69|11 years ago|reply
There is something to be said for the nice clean implementations of some of these tools. There is a little to be said for the language itself.
Really, something bigger and better is needed. A new HTTP server, a new sendmail or something, a new DNS server. I'd love to see Go or Rust take on Bind and produce a safe, secure, high performance implementation. The Ada guys never stepped up and produced anything interesting to show their tools' superiority, there is a lot more interest and community in Rust and Go. What's the leakiest, buggiest part of the equation right now? Go make a better one.
[+] [-] krick|11 years ago|reply
[+] [-] fernly|11 years ago|reply
[1] http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/ab...
[+] [-] lukasm|11 years ago|reply
[+] [-] Symmetry|11 years ago|reply
Rust is sort of like a cross between C++ and Haskell. It has better facilities for abstraction and enforced safety than Go, but at the cost of more cognitive overhead and being harder to learn. People who plan to use it generally use C++ now.
These languages are actually going after different use cases, and for my robot there are some parts of the codebase I'd write in Go if we were re-writing, and some in Rust.
[+] [-] vertex-four|11 years ago|reply
On the other hand, it's also in version 0.10, keeps changing all the time, and the stdlib doesn't contain nearly everything that Go's does, by design.
[+] [-] bjz_|11 years ago|reply
Rust is far more extensible than Go - for example all of the concurrency primitives are built as libraries, and users can create their own depending on their unique use cases. Go's on the other hand are built in, and are difficult to extend.
Rust aims for generic, zero cost abstractions and control over allocation without compromising on safety, but this means the type system is more complex than Go's. Go's static type system is quite simple, and easy to learn, but is hard to write generic abstractions over unless you want to resort to using `interface {}`. Go also uses a mandatory GC which makes low level programming and interfacing with C difficult, but abstracts away from up-front memory management.
Rust's compiler is slow, but generates very fast code because it performs a great deal of static optimizations via LLVM. Go on the other hand builds blazingly fast but performs little to no optimization at compile time, nor compensates for that with a JIT.
If you want raw performance, control over allocation, and an expressive type system, choose Rust. If you want simplicity without having to think about allocation, choose Go.
[+] [-] josteink|11 years ago|reply
If we're going to ditch C for something proper, lets do it properly.
Go just seems like another half-assed minimum effort Google project.
[+] [-] r4um|11 years ago|reply
[+] [-] paulrouget|11 years ago|reply
Why?
Many GNU, Linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to Windows. However, those projects are either old, abandoned, hosted on CVS, written in platform-specific C, etc.
Rust provides a good, platform-agnostic way of writing systems utils that are easy to compile anywhere, and this is as good a way as any to try and learn it.
[+] [-] octo_t|11 years ago|reply
*by replace I mean occupy some of their current marketshare.
[+] [-] ceronman|11 years ago|reply
[+] [-] drsintoma|11 years ago|reply
[+] [-] Dewie|11 years ago|reply
[+] [-] lukasm|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] retroencabulato|11 years ago|reply
[+] [-] grey-area|11 years ago|reply
[+] [-] elktea|11 years ago|reply
I wrote one of the first utilities for this when it was first opened up for collaboration, so I hope it succeeds :) I need to go back and write tests for my util.
[+] [-] icebraining|11 years ago|reply
[+] [-] bronson|11 years ago|reply
Any chance of Rust taking over embedded systems programming? That's still mostly done in C and quickly devolves into horror.
[+] [-] steveklabnik|11 years ago|reply
I don't know about 'taking over' but there are some people who are using Rust for this use case.
[+] [-] SeanDav|11 years ago|reply