Hacker News Reader

Comment by wireprotocol | Hacker News Reader

By using a garbage collector, Go must compete with python, ruby, haskell, clojure, java, scala, c#, etc. Maybe Go is nice for some things, but it seems like an incremental improvement over the next best alternative.

Rust only needs to compete against c, c++, Ada, etc. In that class of languages, safety is a major feature.

View on HN

I find comparing Rust and Go baffling. Both are relatively new, and both compile to native binaries, but their approach and purpose are completely different.

The Go runtime provides GC, its own scheduler, time abstractions -- basically everything a JVM is required to do (plus the scheduler)[1]. It's an AOT-compiled Java. Because of its high-abstraction runtime, interoperation with native libraries is hard to nearly impossible (depending on the direction). It is to be used to write server-side applications. It's Java without the JVM, for better or worse (native binary, short startup, but no dynamic code swapping, no multiple languages support, no instrumentation, no JIT, and no deep monitoring)

Rust, on the other hand, is a modern C/C++ replacement. It is meant to be used anywhere C or C++ are used. It can be used to write applications, device drivers, operating systems, or fully native libraries (that can be called from Java, Go, Python or Fortran).

Neither approach is better than the other, but the two are so different that they can't even be compared directly. One is Java minus the JVM, and the other is a C/C++ replacement.

[1]: GC (or rather the illusion of infinite memory), abstracting OS time plus some other OS abstractions -- all provided by Go but but not Rust), are the only things required from a JVM. Runtime bytecode interpretation or JIT -- what most people usually associate with JVMs -- are actually not required; some JVMs, particularly those for hard realtime and safety critical code, perform AOT compilation.

They are compared because as humans, we are much better at learning new things when contrasted to other things that we are aware of. A concept that has absolutely no parallels with a previously encountered one is much more difficult to understand. From this perspective, it is actually quite useful to compare these two things.

I always thought it was because both languages were (at least at some point) referred to and advertised as 'systems languages', which naturally invited comparisons. However, 'systems' meant different things for each language.

For Go, 'systems' as in the sense of software running on servers providing services to user applications.

For Rust, 'systems' as in the sense of (http://en.wikipedia.org/wiki/System_programming_language) - software such as OSes, device drivers, etc.

Just for fun, Swift is advertised as a systems language as well. In its defense, it does have facilities for bypassing the preferred way of managing memory (ARC) and working with memory directly.

This has indeed encouraged much comparison: there is simply a large overlap in the communities that may be inclined to use either. There was a discussion between the authors of C++, Rust, D, and Go in which the topic of what a "systems programming language" even is is brought into question. Rob Pike, speaking on Go's behalf, mentioned that while "systems programming" was originally advertised as a goal of Go, it has since been dropped from the list, due to the expectations that others have when they read that compared to the intent of the drivers of the language. Here's a video of that talk, if you're curious: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan...

Funny, according to Alexandrescu's definition it is a "systems programming language", after all. Go's memory allocator, garbage collector and runtime are written in Go itself.

I think that if Python can be considered a "systems" language according to somebody's definition, that definition is pretty flawed.

The point is that what constitutes a "system" is not well defined and/or there are multiple conflicting definitions. I was sad to see rust billing itself as a systems language so prominently, given that it doesn't really mean anything.

It's a simple term that, in Rust's case, encompasses all of "bare metal; zero-cost abstractions; no runtime; all language primitives map to simple hardware instructions". I don't see any better word for it. Do you?

That sounds like most of what people mean when they say a low level language, though I admit that the term comes with its own baggage about the simplicity of the language (which doesn't apply to rust).

I guess I think the sentence you wrote above is just a lot more clear than calling it a systems language and hoping people know what you mean.

The two are most compared in communities with a lot webdevs because the last couple of years is when webdevs have started rebounding from the statically typed == bureaucratic enterprise factory bean meme, and will suddenly entertain static types. Then, newly released languages are attractive for the get-in-on-the-ground-floor factor.

They are compared by pretty much anyone that has found both to be significant or interesting. People often compare it to C++ because of the theoretical performance capabilities being similar. People often compare it to Go because Go is a simple, popular reference that many people understand, and hence can be compared against in a way that is meaningful to a lot of people. There are a lot of similarities, as well as a lot of differences, making for lively conversations filled with tangents on various preferences and experiences. In short, you can have a good conversation when making such comparisons. You can compare it against tomatoes, too, but the shared ground isn't huge, and analogies must be far more complex to derive meaning, and the participants need far deeper mental stacks to make ANY progress that relates to the original intent when the tangents veer far from the domain of programming language implementation or usage.

This is so much more important than people are generally aware of. We are leaving the point in time that writing highly bug-prone C or C++ is justifiable due to performance concerns. The justifiability of these up until now is a huge reason why governments and organized crime have been able to buy the keys to our servers and personal machines. We are going to be able to replace ubiquitous, critical, buggy code with something that will significantly increase the costs of finding and exploiting RCE vulnerabilities. This is so huge.

For now, I don't think Rust is as performant as C/C++. Although it should be able to match C/C++ speed, I think there are some cases where the output was slower than expected.

You are absolutely correct. I should say that the THEORETICAL performance of Rust may be competitive with C++, maybe even faster in some cases, but that work remains to be done to get it there. My above statement assumes that this day will come, or that the performance at least reaches a point that will allow a reasonable engineer to choose Rust over C or C++ for something that performance is a crucial consideration for.

There are actually cases where Rust is faster than C already, one of the reasons being the compiler emitting better code thanks to mutable aliasing being forbidden.

http://benchmarksgame.alioth.debian.org/u64q/rust.html

It's not why C is faster, it's more about being able to use hand crafted SSE2 instructions and existing libraries with such optimizations. Nothing competes with C when performance really matters.

Feel free to use the asm! macro in rust when you need to. FFI support is also quite good.

You can use "hand-crafted" SSE2 instructions and libraries with the same in Rust. Servo heavily relies on Skia, for example…

Technically Fortran does compete. For computational applications it is faster than C and hence why it's so popular in supercomputing.

There is also a case for making highly optimized C performance easier to attain, without needing to resort to unsafe code. You can do this by providing more invariants to the compiler via a better type system, which gives it more room to optimize. It may never get to the performance of hand-optimized stuff, but for that there is unsafe code blocks.

I think the point is that machines are fast enough that being as fast as C++ doesn't matter anymore.

True for many things. But there are still plenty of things that we still want to do faster or cheaper or that we want to feed more data to, and we also still find plenty of new things to do as computers get more powerful.

Reply on news.ycombinator.com