Hacker News Reader

Comment by akavlie | Hacker News Reader

Rust seems very similar to Go. Anyone looked at/played with both enough to offer some wisdom on the pros/cons of each language?

View on HN

From the language FAQ: https://github.com/mozilla/rust/wiki/Doc-language-FAQ

Go adopted semantics (safety and memory model) that are quite unsatisfactory.

    Shared mutable state.
    Global GC.
    Null pointers.
    No RAII or destructors.
    No type-parametric user code.

It makes fewer compromises than Go. It'd be more appropriate for concurrent, high performance systems projects, whereas Go is a way to rapid-dev high(er) performance networked services.

What sorts of compromises does Go make (that Rust does not)?

The one that everyone complains about is Go not having generics. I think you have to play around with both languages for long enough to know if it's a real issue; people just seem to look at the spec and decide the lack of generics is a dealbreaker.

No parametric polymorphism, which means plenty of casts, runtime checks, and annotations. This sacrifices performance, compile-time guarantees, and programmer productivity for a simpler and slightly faster compiler.

Garbage collection.

Pertinent to what I said? Garbage collection is the biggie. Utterly unacceptable in systems work.

Both Rust and Go have GCs. It is true that Rust has mostly per-thread GC, which should help to curb performance concerns quite a bit. And Rust aims to have more explicit control over where things are allocated. But it's still a GCed language.

Whether GC is acceptable in systems work depends on what you construe as "systems work" (kernels and GC don't mix nicely; browsers and GC is OK if you're careful).

I'm not an expert systems programmer by any means, but I think that Rust makes a distinction between garbage collection, reference counting, and its region system. There are ways to allocate structures in memory using any of those systems depending on your needs.

If you're willing to be unsafe, it should be possible to avoid most (any?) overhead from automatic memory management. Here's a quote from one of the Rust developers:

"So we basically use the runtime for three things: (a) the task system, which features lightweight threads like Go or Erlang; (b) stack checks and growth; (c) garbage collection. We used to use it for more, but lately more and more stuff has been moved out of the runtime to be written in Rust itself.

"I'd like to see a 'runtime-less Rust' myself, because it'd be great if we could implement the Rust runtime in Rust. This might be useful for other things too, such as drivers or libraries to be embedded into other software. (The latter is obviously of interest to us at Mozilla.) Rust programs compiled in this mode would disable the task system, would be vulnerable to stack overflow (although we might be able to mitigate that with guard pages), and would require extra work to avoid leaks, but would be able to run without a runtime.

"If anyone is interested in this project, I'd be happy to talk more about it -- we have a ton of stuff on our plate at the moment, so we aren't working on it right now, but I'd be thrilled if anyone was interested and could help."

Graydon has been adamant that Rust must provide the ability to avoid tracing GC if the programmer wants. I was at first skeptical, but now I'm fully on board. For things like browsers, control over memory management is crucial.

My understanding is it's GCed depending on types used meaning you can bypass GC if needed.

Rust allows unsafe code and pointer use in the absence of GC.

"Systems language" embraces more than kernels and such.

Go is a new Erlang; its the Erlang for people who don't like Erlang, perhaps?

> Go is a new Erlang;

It very much is not. Erlang's primary goal has always been reliability. Not concurrency. Concurrency arose from a subset of the mechanisms Erlang "needed" to implement reliability, but was not a primary focus of the language (just look how long Erlang lived without an SMP-able runtime).

Yet this concurrency is pretty much the only Erlang feature that was ported to Go, in a much less reliable manner.

Are you confusing concurrency with parallelism?

> Erlang's primary goal has always been reliability. Not concurrency

Wrong. Concurrency is not some accidental bolt-on in Erlang: http://www.erlang.org/course/history.html

Now I picked out Erlang because it has ... garbage collection. I was replying to the parent saying that GC is utterly incompatible with a systems language.

Go and Rust are the new Erlangs in that they are the go-to language for system services above kernel level.

Erlang disallows shared memory in favour of per-process gc. Whether or not this is a good tradeoff in general is debatable but it is what makes the gc acceptable in soft-realtime environments. Go makes a different set of tradeoffs (shared mutable memory, whole process gc, no hot code reloading) which place it in a different niche to erlang.

> Are you confusing concurrency with parallelism?

No.

> Wrong. Concurrency is not some accidental bolt-on in Erlang

You might want to read my comment correctly and avoid injecting things which are not in it. I did not say concurrency was "bolted on", I said it was not a primary goal of Erlang's design, it was merely one of the tool deployed to reach the over-arching goal of reliability.

> I was replying to the parent saying that GC is utterly incompatible with a systems language.

Can't say I've ever seen Erlang called a systems language. But in any case Erlang's design and VM structure does make it suitable for soft real-time (per-process shared-nothing[0] heaps independently GC'd with configurable initial heaps, allowing such things as never GC'ing a process at all). Go still's no Erlang.

[0] aside from reference counted big binaries

Reply on news.ycombinator.com