Hacker News Reader

Comment by lukasm | Hacker News Reader

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

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

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.

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.

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

I used to agree with Rust approach, assuming the compiler does dataflow analysis to minimize needless refcounting.

Now that the refcounting is also moved to a library, I am not sure.

Or are those types known to the compiler and the respective optimizations applied?

They fall out automatically from move semantics, a reference count only occurs on an explicit clone call:

  fn just_a_ref(x: &T) { ... }
  fn rc_by_val(x: Rc<T>) { ... }
  fn rc_by_ref(x: &Rc<T>) { ... }

  let some_rc_pointer: Rc<T> = ...;

  just_a_ref(&*some_rc_pointer); // no ref counting
  rc_by_ref(&some_rc_pointer); // no ref counting

  rc_by_val(some_rc_pointer.clone()); // ref count incremented

  // last use of a value (statically guaranteed that 
  // some_rc_pointer is never used again):
  rc_by_val(some_rc_pointer); // no ref counting

Thanks for the clarification.

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.

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.

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.

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.

Written in Go https://github.com/aisola/go-coreutils https://github.com/sepeth/go-coreutils

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.

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.

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.

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.

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.

Porting the core utils was never a language problem - it's always been a "the terminal works pretty fundamentally differently on Windows" problem.

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

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.

not the mention the way disks, processes (unix forks and execs, windows spawns) and I/O work

And character sets. A lot of poorly-done ports of Unix software cannot cope with Unicode on Windows.

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.

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.

Simply comparing the two based on GC is very superficial.

But if GC doesn't matter, then why Go and not something like Lua?

Not really. The day my `cat` pauses to GC is the day I leave this field...

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

interestingly, Go was originally envisioned to do exactly this - a systems development language

Well, they used the phrase "systems language" when they introduced it, and it still appears prominently in the FAQ, but what they had in mind vis-a-vis what-exactly-constitutes-a-system was very different. (They were thinking more along the lines of a cloud infrastructure language.)

If you watch this excellent panel discussion from this year, you can hear Rob Pike express how they later regretted how their poor choice of terminology created such confusion:

http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan...

(approx 6 minutes 45 seconds into the talk)

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.

The last time I played around with rust (a few weeks ago), rustc compiled binaries included a statically linked runtime as well.

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.

It goes a lot smaller with `--codegen prefer-dynamic`, also around 6K for me.

But AFAIK there is a subset of Rust which doesn't require the runtime.

The language itself doesn't need the runtime: it's entirely implemented in libraries, and the libraries are slowly being rearranged to offer as much as possible to clients who wish to avoid the runtime (e.g. "libcore").

High-level description the runtimes: http://doc.rust-lang.org/master/guide-runtime.html

Avoiding the standard library/runtime: http://doc.rust-lang.org/master/guide-unsafe.html#avoiding-t... (don't miss the "Using libcore" subsection)

Rust gives you the option of either static or dynamic linking, but prefers static linking by default.

Maybe they could design it like BusyBox where there is a single binary and a bunch of symlinks to it.

You can use gccgo for dynamic linking.

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.

No sure about the downvotes. It seems that Rust has better explicit resource management.

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.

Or, say, C?

Why not?

Reply on news.ycombinator.com