20 ms·

Cross-platform Rust Rewrite of the GNU Coreutils

299 points by doppp 12y ago

lukasm 12y ago
Why Rust? Is it better at this than, say, Go?
- paulrouget 12y ago
  From the README: 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.
  - XorNot 12y ago
    Porting the core utils was never a language problem - it's always been a "the terminal works pretty fundamentally differently on Windows" problem.
    - pdw 12y ago
      The file system and security model differences are much more important than any terminal differences. Looking through the programs included in coreutils, I can see only two or three that care about the terminal at all (`stty`, `nohup`, ls output coloring).
      - TorKlingberg 12y ago
        I think "terminal" here also includes differences in the shell. For example if you type "command *", a Unix shell will expand the star before calling the command. On Windows the star is passed to the command.
        calvin_ 12y ago
        not the mention the way disks, processes (unix forks and execs, windows spawns) and I/O work
        ygra 12y ago
        And character sets. A lot of poorly-done ports of Unix software cannot cope with Unicode on Windows.
  - pjc50 12y ago
    Cygwin does a very good job of letting you use UNIX utils on windows. But because it's hosted on CVS, that makes it uncool and worthy of a rewrite? I've nothing against rewriting coreutils in Rust as part of a project to produce a "Rust operating system" in the same way that UNIX is the "C operating system". I do find "project rejected due to not on github" to be silly and a slightly unpleasant trend.
    - asveikau 12y ago
      I don't know how the rust runtime or this project achieves portability, but I don't think cygwin is a great example. It might appear to work well on the surface but it is a heavy layer, which comes at performance cost and is somewhat inelegant. Maybe cygwin is OK if you are fine with the costs and want to maximize the amount of Unix-like functionality (and you don't hit the bugs - I have seen some very nasty ones in the cygwin dll - deadlocks, random crashes). But something like MinGW/msys does a much better job of compiling for Windows.
    - fithisux 12y ago
      Let me rephrase it more accurately "Cygwin does a very good job of trashing your HD on windows." It cost me 90 euros for two hard drives.
      - pjc50 12y ago
        How on earth did it manage to do that? Two drives? Not recoverable by formatting? I didn't think it even installed in the driver layer.
- octo_t 12y ago
  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.
  - justincormack 12y ago
    Very few of the coreutils would be affected by gc. You could probably write them all to barely allocate memory other than at startup if you wanted, and most of the garbage would be produced by the parsing.
  - retroencabulato 12y ago
    Simply comparing the two based on GC is very superficial.
    - Touche 12y ago
      But if GC doesn't matter, then why Go and not something like Lua?
    - __david__ 12y ago
      Not really. The day my `cat` pauses to GC is the day I leave this field...
      - lomnakkus 12y ago
        Why? Do you think you would notice? (I realize your post may have been tongue in cheek, but it can be hard to tell on the interwebs.)
      - deleted 12y ago
        [deleted]
  - SixSigma 12y ago
    interestingly, Go was originally envisioned to do exactly this - a systems development language
- vertex-four 12y ago
  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.
  - kibwen 12y ago
    The Rust stdlib will not be as comprehensive as Go's, but it will still be much more "batteries included" than systems programmers have come to expect.
- retroencabulato 12y ago
  Or, say, C?
- r4um 12y ago
  Written in Go https://github.com/aisola/go-coreutils https://github.com/aisola/go-coreutils https://github.com/sepeth/go-coreutils https://github.com/sepeth/go-coreutils
- drsintoma 12y ago
  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.
  - stefantalpalaru 12y ago
    You can use gccgo for dynamic linking.
  - hendzen 12y ago
    The last time I played around with rust (a few weeks ago), rustc compiled binaries included a statically linked runtime as well.
    - simias 12y ago
      I've just built rust from the latest git and it still seems true (at least with the default compiler flags). The "hello world" from the tutorial compiles to a 1MB executable (dynamically linked with the C library but statically linked with the rust library). The equivalent C program creates a 6.5KB binary with gcc.
      - ben0x539 12y ago
        It goes a lot smaller with `--codegen prefer-dynamic`, also around 6K for me.
        steveklabnik 12y ago
        See also https://github.com/mozilla/rust/issues/13871 https://github.com/mozilla/rust/issues/13871
      - mercurial 12y ago
        But AFAIK there is a subset of Rust which doesn't require the runtime.
        12y ago
- josteink 12y ago
  Go may have gotten a headstart, but Rust seems like a much more worthwhile language to work with. 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.
- grey-area 12y ago
  Why not?
- lukasm 12y ago
  No sure about the downvotes. It seems that Rust has better explicit resource management.
  - klibertp 12y ago
    The downvotes: your original comment is very easy to mistake for trolling and/or Go fanboyism. I gave you an upvote, because I gave you benefit of a doubt and assumed that was an honest question.
- ceronman 12y ago
  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.
- deleted 12y ago
  [deleted]
- Symmetry 12y ago
  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.
  - kzrdude 12y ago
    Rust is also a bit like C (and not C++) by not having implicit calls to constructors, copy constructors etc, so its values are less magic.
    - malandrew 12y ago
      Less magic is such a good value to have. You can always make magic from unmagic pieces, but it's not possible to de-magic-ify magic. For example, I really dug the decision to remove GC from the Rust language and move it to the standard library.
      - pjmlp 12y ago
        Having a GC as a library type means many optimizations that need compiler help are not possible unless the library types are "magic" to the compiler.
        kibwen 12y ago
        Even if the GC were in the language, the optimizations that you speak of would have negative performance ramifications on all code that did not use GC. The reason that we took the plunge and moved GC into the stdlib was because we weren't willing to make that sacrifice. It does mean that our GC will never be particularly optimal. And that's fine, because if you really need shared ownership you should be using our really great refcounted pointers instead. :)
- Dewie 12y ago
  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.
- bjz_ 12y ago
  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.
reirob 12y ago
"uutils is licensed under the MIT License - see the LICENSE file for details" - funny to see GNU software reimplemented in another open source license.
- endgame 12y ago
  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.
  - jessaustin 12y ago
    I'm a big GNU fan, and actually prefer to use the AGPL, but I don't understand this opinion. It seems to contradict the whole concept of free software. EDIT: Thanks for the informative responses! This sort of effort might ought to receive the occasional audit, which probably could be done in semi-automated fashion.
    - dllthomas 12y ago
      Looking at source for something implementing the same thing opens you to accusations of being a derivative work. If the licenses are compatible, then this is no downside. If the licenses are incompatible, this makes it harder to defend against a lawsuit (even if you probably, in principle, remain in the right).
      - cwyers 12y ago
        The MIT license is compatible with the GPL; you can use MIT-licensed code in GPL projects.
        icebraining 12y ago
        Yes, but the reverse is not true; you can't use GPL-licensed code on your project and still distribute it all as MIT-licensed.
DCKing 12y ago
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'.
- nly 12y ago
  Total language displacement is a pretty rare event, and technical superiority isn't even a prerequisite. And I happen to like having a preprocessor.
  - DCKing 12y ago
    Yes, it's far too early to tell. The good thing to take away is that, at the moment, the answer to "is Rust a viable threat to C/C++?" does not seem to be a categorical no. The same cannot be said for other languages in the area, such as Pascal, D, Ada, Nimrod and even Go, although all of these languages have their use. Any adoption of Rust in areas where people otherwise use C/C++ is an improvement I think. It doesn't have to be total displacement, and that will never happen.
    - pjmlp 12y ago
      Any systems programming language can displace C. You just need a successful OS vendor pushing the said language as only means to target their OS.
      - DCKing 12y ago
        I think the reason many people are rooting for Rust is because it's got comprehensively better features than competing languages. I'm not talking just about memory safety, but also its adoption of functional language features. I'm of the opinion that immutability-by-default, pattern matching, first-class functions and real macros combined with no garbage collection are a Very Good Thing™ for this type of language (and I'm not the only one). So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers.
cageface 12y ago
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.
- dbaupp 12y ago
  Rust's internal ABI (i.e. used for a default `fn foo() { ... }`) is not at all stable/usable/specified. However, you can easily define a function with a C ABI (and a non-mangled symbol name): #[no_mangle] pub extern "C" fn foo() { ... } I'm not sure if you regard this as better than C++'s situation.
- reubenmorais 12y ago
  You might be interested in the Portable C++ ABI proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n402... Considering how quickly C++ compilers are iterating, it might even be available in GCC/Clang before Rust 1.0.
mhd 12y ago
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).
- Nelson69 12y ago
  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.
  - v21 12y ago
    Well, they're building a browser engine...
SeanDav 12y ago
Interesting project. Why is there no grep in this, or on the to-do list?
- delroth 12y ago
  grep is not part of the coreutils.
krick 12y ago
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…
elktea 12y ago
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.
- icebraining 12y ago
  There are many "libc"s; according to the docs, Rust's libc is a module that binds to the platform-specific libc implementation: http://static.rust-lang.org/doc/0.10/std/libc/index.html http://static.rust-lang.org/doc/0.10/std/libc/index.html
pixelbeat 12y ago
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. Some stats: coreutils files, lines, commits: 1072, 239474, 27924 gnulib files, lines, commits: 9274, 302513, 17476
- 3JPLW 12y ago
  Would using a GPL test suite with an MIT implementation make the whole GPL? You're not "linking" to it, but it'd worry me somewhat.
  - gkya 12y ago
    IANAL, but AFAIK as long as the test suite is not distributed as part of the package, it does not affect the licensing of the package as a whole; whereas if the test suite is distributed with the package, then the whole package can only be distributed under GPL, but the original sources the package authors wrote need not be relicensed. So, the sources will be MIT, the test suite will be GPL, and the whole package, including both the test suite and the sources will have to be GPL.
    - dalke 12y ago
      Nor am I a lawyer, but I'll point out that the GPL is only based in copyright, so if there's no chance of copyright infringement then the GPL terms don't apply. I believe the relevant part of the GPLv3, regarding "whole package" is: > A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
loudmax 12y ago
While they're at it, I hope they write complete man pages rather than pointers to info pages.
- gkya 12y ago
  Amen.
- davexunit 12y ago
  info > man
- malandrew 12y ago
  While I know the basic differences between info and man pages, can you shed some more light on your preference here for the less well informed.
  - asher 12y ago
    Man pages are more convenient for the typical unix hacker - command-line oriented, vi-using. They are rendered in less, which supports vi-like searching. Info, on the other hand, is one of those odd pre-www hypertext systems. Advanced for its time, it is now clumsy and nonstandard.
  - loudmax 12y ago
    What asher said. Man pages are convenient and man works nicely with other Unix command line tools. Info behaves more like a browser and plays by its own rules. Its not that I want to discourage anybody from using their preferred documentation resource. If a developer would rather spend their time writing info pages, that's okay. But at least dump it into a man page. Even an oversized man paged like the one for mplayer is preferable to a pithy page telling me to use info. If I want something with hyperlinks I'll check the web.
- pixelbeat 12y ago
  I see what you're saying, but then you'd have people complaining there was too much text in the man page. Note the info pages are available on the web so you could have a wrapper like: cinfo() { xdg-open "http://www.gnu.org/software/coreutils/manual/html_node/$1-invocation.html#$1-invocation"; } Which you could use like: cinfo dd
gkya 12y ago
> 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?
- thegeomaster 12y ago
  I know from my own experience—when you want to start a project that has been done before you, it's easy to fall into the trap of faultily rationalizing why none of the other attempts have worked and why you're going to do it better. However, I don't think you should ever avoid writing something you'd enjoy for the sole reason that there are prior attempts (successful or unsuccessful). If you aren't motivated by money, you won't lose anything if your project doesn't get a single user, but you will always gain enlightenment and great experience.
  - gkya 12y ago
    I understand your comment and support it -- I have, many times, thought of implementing a POSIX userland in Go, but the task has daunted me, so that has not been realised till now. What bothered me was the fact that they show usage of CVS as an alert for deprecation. I concur your argument though, no-one can judge no-one else for what they choose the create in their own time. But CVS is perfectly usable software (and I am telling this as someone who has spent a month trying to CVS-checkout OpenBSD source tree, only because $CVS_RSH=rsh rather than ssh).
    - thegeomaster 12y ago
      I agree with you completely. CVS is old, but that doesn't make it bad per se. If it could serve the needs of source control before, I doubt the needs have changed that much to require a different SCM tool. We just see new solutions that work better so we naturally migrate to them. My point is that the argument for CVS is probably just a forced, faulty rationalization by the author so he/she can justify writing a new implementation. But I'm repeating again that there is nothing wrong in reimplementing something just for the sake of it—you have nothing to lose and a lot to gain :)
bronson 12y ago
I love this idea! When I get a few hours I'll have to try porting a small coreutil... Seems like a great way to learn Rust. Any chance of Rust taking over embedded systems programming? That's still mostly done in C and quickly devolves into horror.
- steveklabnik 12y ago
  > Any chance of Rust taking over embedded systems programming? I don't know about 'taking over' but there are some people who are using Rust for this use case.
  - bronson 12y ago
    That would be super cool. Anything publicly available to look at? Freescale's Freedom boards are so cheap, so capable, and have such miserable tooling (mbed, DIY usb, Processor Expert, CodeWarrior, ugh)... I wonder if Rust could make them attractive.
    - steveklabnik 12y ago
      I just know that people come into IRC, and there was some discussion about bitfields to help support embedded stuff. Not sure there's a lot written about it yet.
fernly 12y ago
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. [1] http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/abstract http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/ab...

299 points by doppp 12y ago

lukasm 12y ago

Why Rust? Is it better at this than, say, Go?

paulrouget 12y ago
From the README: 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.
- XorNot 12y ago
  Porting the core utils was never a language problem - it's always been a "the terminal works pretty fundamentally differently on Windows" problem.
  - pdw 12y ago
    The file system and security model differences are much more important than any terminal differences. Looking through the programs included in coreutils, I can see only two or three that care about the terminal at all (`stty`, `nohup`, ls output coloring).
    - TorKlingberg 12y ago
      I think "terminal" here also includes differences in the shell. For example if you type "command *", a Unix shell will expand the star before calling the command. On Windows the star is passed to the command.
      - calvin_ 12y ago
        not the mention the way disks, processes (unix forks and execs, windows spawns) and I/O work
        ygra 12y ago
        And character sets. A lot of poorly-done ports of Unix software cannot cope with Unicode on Windows.
- pjc50 12y ago
  Cygwin does a very good job of letting you use UNIX utils on windows. But because it's hosted on CVS, that makes it uncool and worthy of a rewrite? I've nothing against rewriting coreutils in Rust as part of a project to produce a "Rust operating system" in the same way that UNIX is the "C operating system". I do find "project rejected due to not on github" to be silly and a slightly unpleasant trend.
  - asveikau 12y ago
    I don't know how the rust runtime or this project achieves portability, but I don't think cygwin is a great example. It might appear to work well on the surface but it is a heavy layer, which comes at performance cost and is somewhat inelegant. Maybe cygwin is OK if you are fine with the costs and want to maximize the amount of Unix-like functionality (and you don't hit the bugs - I have seen some very nasty ones in the cygwin dll - deadlocks, random crashes). But something like MinGW/msys does a much better job of compiling for Windows.
  - fithisux 12y ago
    Let me rephrase it more accurately "Cygwin does a very good job of trashing your HD on windows." It cost me 90 euros for two hard drives.
    - pjc50 12y ago
      How on earth did it manage to do that? Two drives? Not recoverable by formatting? I didn't think it even installed in the driver layer.
octo_t 12y ago
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.
- justincormack 12y ago
  Very few of the coreutils would be affected by gc. You could probably write them all to barely allocate memory other than at startup if you wanted, and most of the garbage would be produced by the parsing.
- retroencabulato 12y ago
  Simply comparing the two based on GC is very superficial.
  - Touche 12y ago
    But if GC doesn't matter, then why Go and not something like Lua?
  - __david__ 12y ago
    Not really. The day my `cat` pauses to GC is the day I leave this field...
    - lomnakkus 12y ago
      Why? Do you think you would notice? (I realize your post may have been tongue in cheek, but it can be hard to tell on the interwebs.)
    - deleted 12y ago
      [deleted]
- SixSigma 12y ago
  interestingly, Go was originally envisioned to do exactly this - a systems development language
vertex-four 12y ago
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.
- kibwen 12y ago
  The Rust stdlib will not be as comprehensive as Go's, but it will still be much more "batteries included" than systems programmers have come to expect.
retroencabulato 12y ago
Or, say, C?
r4um 12y ago
Written in Go https://github.com/aisola/go-coreutils https://github.com/aisola/go-coreutils https://github.com/sepeth/go-coreutils https://github.com/sepeth/go-coreutils
drsintoma 12y ago
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.
- stefantalpalaru 12y ago
  You can use gccgo for dynamic linking.
- hendzen 12y ago
  The last time I played around with rust (a few weeks ago), rustc compiled binaries included a statically linked runtime as well.
  - simias 12y ago
    I've just built rust from the latest git and it still seems true (at least with the default compiler flags). The "hello world" from the tutorial compiles to a 1MB executable (dynamically linked with the C library but statically linked with the rust library). The equivalent C program creates a 6.5KB binary with gcc.
    - ben0x539 12y ago
      It goes a lot smaller with `--codegen prefer-dynamic`, also around 6K for me.
      - steveklabnik 12y ago
        See also https://github.com/mozilla/rust/issues/13871 https://github.com/mozilla/rust/issues/13871
    - mercurial 12y ago
      But AFAIK there is a subset of Rust which doesn't require the runtime.
      - 12y ago
josteink 12y ago
Go may have gotten a headstart, but Rust seems like a much more worthwhile language to work with. 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.
grey-area 12y ago
Why not?
lukasm 12y ago
No sure about the downvotes. It seems that Rust has better explicit resource management.
- klibertp 12y ago
  The downvotes: your original comment is very easy to mistake for trolling and/or Go fanboyism. I gave you an upvote, because I gave you benefit of a doubt and assumed that was an honest question.
ceronman 12y ago
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.
deleted 12y ago
[deleted]
Symmetry 12y ago
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.
- kzrdude 12y ago
  Rust is also a bit like C (and not C++) by not having implicit calls to constructors, copy constructors etc, so its values are less magic.
  - malandrew 12y ago
    Less magic is such a good value to have. You can always make magic from unmagic pieces, but it's not possible to de-magic-ify magic. For example, I really dug the decision to remove GC from the Rust language and move it to the standard library.
    - pjmlp 12y ago
      Having a GC as a library type means many optimizations that need compiler help are not possible unless the library types are "magic" to the compiler.
      - kibwen 12y ago
        Even if the GC were in the language, the optimizations that you speak of would have negative performance ramifications on all code that did not use GC. The reason that we took the plunge and moved GC into the stdlib was because we weren't willing to make that sacrifice. It does mean that our GC will never be particularly optimal. And that's fine, because if you really need shared ownership you should be using our really great refcounted pointers instead. :)
Dewie 12y ago
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.
bjz_ 12y ago
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.

reirob 12y ago

"uutils is licensed under the MIT License - see the LICENSE file for details" - funny to see GNU software reimplemented in another open source license.

endgame 12y ago
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.
- jessaustin 12y ago
  I'm a big GNU fan, and actually prefer to use the AGPL, but I don't understand this opinion. It seems to contradict the whole concept of free software. EDIT: Thanks for the informative responses! This sort of effort might ought to receive the occasional audit, which probably could be done in semi-automated fashion.
  - dllthomas 12y ago
    Looking at source for something implementing the same thing opens you to accusations of being a derivative work. If the licenses are compatible, then this is no downside. If the licenses are incompatible, this makes it harder to defend against a lawsuit (even if you probably, in principle, remain in the right).
    - cwyers 12y ago
      The MIT license is compatible with the GPL; you can use MIT-licensed code in GPL projects.
      - icebraining 12y ago
        Yes, but the reverse is not true; you can't use GPL-licensed code on your project and still distribute it all as MIT-licensed.

DCKing 12y ago

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

nly 12y ago
Total language displacement is a pretty rare event, and technical superiority isn't even a prerequisite. And I happen to like having a preprocessor.
- DCKing 12y ago
  Yes, it's far too early to tell. The good thing to take away is that, at the moment, the answer to "is Rust a viable threat to C/C++?" does not seem to be a categorical no. The same cannot be said for other languages in the area, such as Pascal, D, Ada, Nimrod and even Go, although all of these languages have their use. Any adoption of Rust in areas where people otherwise use C/C++ is an improvement I think. It doesn't have to be total displacement, and that will never happen.
  - pjmlp 12y ago
    Any systems programming language can displace C. You just need a successful OS vendor pushing the said language as only means to target their OS.
    - DCKing 12y ago
      I think the reason many people are rooting for Rust is because it's got comprehensively better features than competing languages. I'm not talking just about memory safety, but also its adoption of functional language features. I'm of the opinion that immutability-by-default, pattern matching, first-class functions and real macros combined with no garbage collection are a Very Good Thing™ for this type of language (and I'm not the only one). So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers.

cageface 12y ago

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.

dbaupp 12y ago
Rust's internal ABI (i.e. used for a default `fn foo() { ... }`) is not at all stable/usable/specified. However, you can easily define a function with a C ABI (and a non-mangled symbol name): #[no_mangle] pub extern "C" fn foo() { ... } I'm not sure if you regard this as better than C++'s situation.
reubenmorais 12y ago
You might be interested in the Portable C++ ABI proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n402... Considering how quickly C++ compilers are iterating, it might even be available in GCC/Clang before Rust 1.0.

mhd 12y ago

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

Nelson69 12y ago
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.
- v21 12y ago
  Well, they're building a browser engine...

SeanDav 12y ago

Interesting project. Why is there no grep in this, or on the to-do list?

delroth 12y ago
grep is not part of the coreutils.

krick 12y ago

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…

elktea 12y ago

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.

icebraining 12y ago
There are many "libc"s; according to the docs, Rust's libc is a module that binds to the platform-specific libc implementation: http://static.rust-lang.org/doc/0.10/std/libc/index.html http://static.rust-lang.org/doc/0.10/std/libc/index.html

pixelbeat 12y ago

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. Some stats: coreutils files, lines, commits: 1072, 239474, 27924 gnulib files, lines, commits: 9274, 302513, 17476

3JPLW 12y ago
Would using a GPL test suite with an MIT implementation make the whole GPL? You're not "linking" to it, but it'd worry me somewhat.
- gkya 12y ago
  IANAL, but AFAIK as long as the test suite is not distributed as part of the package, it does not affect the licensing of the package as a whole; whereas if the test suite is distributed with the package, then the whole package can only be distributed under GPL, but the original sources the package authors wrote need not be relicensed. So, the sources will be MIT, the test suite will be GPL, and the whole package, including both the test suite and the sources will have to be GPL.
  - dalke 12y ago
    Nor am I a lawyer, but I'll point out that the GPL is only based in copyright, so if there's no chance of copyright infringement then the GPL terms don't apply. I believe the relevant part of the GPLv3, regarding "whole package" is: > A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

loudmax 12y ago

While they're at it, I hope they write complete man pages rather than pointers to info pages.

gkya 12y ago
Amen.
davexunit 12y ago
info > man
malandrew 12y ago
While I know the basic differences between info and man pages, can you shed some more light on your preference here for the less well informed.
- asher 12y ago
  Man pages are more convenient for the typical unix hacker - command-line oriented, vi-using. They are rendered in less, which supports vi-like searching. Info, on the other hand, is one of those odd pre-www hypertext systems. Advanced for its time, it is now clumsy and nonstandard.
- loudmax 12y ago
  What asher said. Man pages are convenient and man works nicely with other Unix command line tools. Info behaves more like a browser and plays by its own rules. Its not that I want to discourage anybody from using their preferred documentation resource. If a developer would rather spend their time writing info pages, that's okay. But at least dump it into a man page. Even an oversized man paged like the one for mplayer is preferable to a pithy page telling me to use info. If I want something with hyperlinks I'll check the web.
pixelbeat 12y ago
I see what you're saying, but then you'd have people complaining there was too much text in the man page. Note the info pages are available on the web so you could have a wrapper like: cinfo() { xdg-open "http://www.gnu.org/software/coreutils/manual/html_node/$1-invocation.html#$1-invocation"; } Which you could use like: cinfo dd

gkya 12y ago

> 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?

thegeomaster 12y ago
I know from my own experience—when you want to start a project that has been done before you, it's easy to fall into the trap of faultily rationalizing why none of the other attempts have worked and why you're going to do it better. However, I don't think you should ever avoid writing something you'd enjoy for the sole reason that there are prior attempts (successful or unsuccessful). If you aren't motivated by money, you won't lose anything if your project doesn't get a single user, but you will always gain enlightenment and great experience.
- gkya 12y ago
  I understand your comment and support it -- I have, many times, thought of implementing a POSIX userland in Go, but the task has daunted me, so that has not been realised till now. What bothered me was the fact that they show usage of CVS as an alert for deprecation. I concur your argument though, no-one can judge no-one else for what they choose the create in their own time. But CVS is perfectly usable software (and I am telling this as someone who has spent a month trying to CVS-checkout OpenBSD source tree, only because $CVS_RSH=rsh rather than ssh).
  - thegeomaster 12y ago
    I agree with you completely. CVS is old, but that doesn't make it bad per se. If it could serve the needs of source control before, I doubt the needs have changed that much to require a different SCM tool. We just see new solutions that work better so we naturally migrate to them. My point is that the argument for CVS is probably just a forced, faulty rationalization by the author so he/she can justify writing a new implementation. But I'm repeating again that there is nothing wrong in reimplementing something just for the sake of it—you have nothing to lose and a lot to gain :)

bronson 12y ago

I love this idea! When I get a few hours I'll have to try porting a small coreutil... Seems like a great way to learn Rust. Any chance of Rust taking over embedded systems programming? That's still mostly done in C and quickly devolves into horror.

steveklabnik 12y ago
> Any chance of Rust taking over embedded systems programming? I don't know about 'taking over' but there are some people who are using Rust for this use case.
- bronson 12y ago
  That would be super cool. Anything publicly available to look at? Freescale's Freedom boards are so cheap, so capable, and have such miserable tooling (mbed, DIY usb, Processor Expert, CodeWarrior, ugh)... I wonder if Rust could make them attractive.
  - steveklabnik 12y ago
    I just know that people come into IRC, and there was some discussion about bitfields to help support embedded stuff. Not sure there's a lot written about it yet.

fernly 12y ago

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. [1] http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/abstract http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/ab...