11 ms·

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.