7 ms·

Computer Language Benchmarks Game – Rust vs. Go

59 points by riccomini 12y ago

SwellJoe 12y ago
Had I been asked "which do you think is faster, on average?" I would have guessed Go. I'm not sure why but that was my gut feeling. Rust feels newer and less developed (though they are both similar in age), to me, and also more ambitious in some regards. But, this turns that on its head. Microbenchmarks are, of course, to be taken with a grain of salt, but it's still a useful data point. More useful would be a discussion of why it is so.
- samnardoni 12y ago
  Rust uses LLVM, which does all the optimisation. Go generates the machine code itself and its optimisation is pretty weak compared to LLVM.
  - SwellJoe 12y ago
    An older version of the benchmarks discussed on the Go mailing list was done with GCCGO (which I assume is Go with a GCC backend). Given that GCC is historically ahead of LLVM on CPU optimizations (a gap that has shrunk in recent years), I'm guessing that's not a complete answer. But, if it is the primary source, it would tell me that Go will close the gap as the compiler becomes more advanced and takes advantage of more CPU optimization features. Also, it's an interesting difference that Rust is an LLVM language while Go is compiled to native code directly; probably not from a performance perspective (at least not in the long run), but from a development perspective...is it easier or harder to develop new language features on LLVM or a native compiler? https://groups.google.com/forum/#!topic/golang-nuts/NSPcEqhe-8I https://groups.google.com/forum/#!topic/golang-nuts/NSPcEqhe...
    - dbaupp 12y ago
      Note: despite the "VM" in the name LLVM is a native compiler: the rust compiler constructs the appropriate internal representation to LLVM and passes it to LLVM for optimisation and native code generation. There's not really a fundamental difference between this and writing the code generation step in pure Rust other than the latter missing out on all the benefits (speed, architecture support etc) of LLVM. That is to say: there's not much difference for difficulty of developing new language features, but avoiding LLVM makes it harder to develop new fast language features.
- mamcx 12y ago
  Exist a well rounded samples for benchmark compilers?, I mean, not just micro, but more complete?
- wycats 12y ago
  A design goal of Rust is to target the performance of well-written, safe C++. It doesn't (today) even ship with a garbage collector, discourages heap allocation (which is your only option in normal Go), and avoids dynamic dispatch in the vast majority of cases. In contrast, idiomatic Go code is garbage collected, heap allocation heavy, and dynamic dispatch heavy. That isn't always going to mean that Rust code is faster, but for benchmark games like this, when Rust is slower it almost always means that the benchmark is wrong.
  - SwellJoe 12y ago
    I read an article recently about memory in Go (the "why is my go program 138GB!?" article), which was enlightening and also weird. I don't have any experience with either language, but have plans to learn a smattering of both in 2015. As for dynamic dispatch...does Rust not support it, or is there some language construct that allows solving the problems dynamic dispatch solves without imposing annoying limitations or needless verbosity? And, aren't there fast implementations of dynamic dispatch?
    - steveklabnik 12y ago
      Rust supports both. You might enjoy reading http://programmers.stackexchange.com/a/247313 http://programmers.stackexchange.com/a/247313
    - wycats 12y ago
      > As for dynamic dispatch...does Rust not support it, or is there some language construct that allows solving the problems dynamic dispatch solves without imposing annoying limitations or needless verbosity? Rust supports dynamic dispatch if you truly need it, but the normal approach is to use trait bounds, which the compiler expands when used. Here's an example: fn main() { let r = MemReader::new("hello world\n".as_bytes()); get_line(&r); } fn get_line<R: Buffer>(r: &R) -> IoResult<String> { r.read_line() } In this very simple example, the `get_line` function takes any value that implements the `Buffer` trait, which provides the `read_line` method. When `get_line` is called inside of `main`, the compiler creates a special version of `get_line` that takes a `MemReader`, and dispatches to its implementation of `read_line` statically. In practice, this feels a lot like dynamic dispatch, but using trait bounds always results in static dispatch in practice. Also, in this example, the `MemReader` is stack-allocated, and lent to the `get_line` method. In very rare cases, you may want dynamic dispatch. For example, imagine you have an array of Buffers, and want to read a line from each of them. In this case, you use a "trait object" (a `Box<Buffer>`), which moves the object to the heap and allows dynamic dispatch. In practice, I have written many thousands of lines of production Rust code and have only encountered a need for trait objects a handful of times. This means that idiomatic, normal Rust code is stack-allocated and statically dispatched. The verbosity of trait bounds has decreased more and more over time, and my favorite proposal (by aturon) for making it pretty close to maximally ergonomic is: fn main() { let r = MemReader::new("hello world\n".as_bytes()); get_line(&r); } fn get_line(r: &impl Reader) -> IoResult<String> { r.read_line() } I hope this lands as new syntax after 1.0 :)
- pdpi 12y ago
  There's not even a chance at a competition, because of their respective design goals. Go is explicitly meant to have _really_ fast compilation times, which precludes the Go compilers from any expensive optimisations. Rust, on the other hand, has an explicit goal of being as fast as idiomatic/safe C/C++ while removing the burden of writing the safety yourself, so it really _has_ to be fast.
- chipsy 12y ago
  You can typically predict performance behaviors across a whole language based on memory allocation patterns and the type system. If automatic memory management is built in, that adds some overhead to most allocation situations(and encourages an architecture that exploits easy allocation - e.g. Java libraries where everything you do involves a new()). There are differences between garbage collection(mark-and-sweep) and reference counting as well; an RC system is "pay for what you allocate" with predictable scaling, making it more appropriate to employ for hitting real-time deadlines, however, the state-of-the-art in generational mark-and-sweep GC does better for average case throughput. Or to put it another way, if you have a single batch process that everything goes through, you can usually count on a GC system doing it faster than a RC equivalent. But if you want to run several things concurrently and tally results, or you are running an interactive app and care about getting your latency numbers down, the pauses involved in GC may be more problematic to you. (The semantic downside of RC, which has also made a lot of languages avoid it, is its inability to deal with circular data references.) Of course, manually managed memory lets you design any allocation strategy you want, and so it can let you blow away automatically managed systems on microbenchmarks like these - stuff that starts mattering in the real world only after you've scaled up near to the constraints of the target hardware and any overhead is a Really Big Problem. There's definitely some more experimental automatic technology out there that "breaks the rules," but in terms of what you see in today's production environments, you can start estimating performance characteristics just by knowing what type of allocation is being done. The other big issue, of course, is the type system. The design of the type system determines the constraints and difficulty of automated optimizations; classically, Fortran was one of the best languages for low-level optimization because it made things very easy for the compiler, and offloaded many considerations on the programmer. Today C has grown into a roughly equivalent space(pointer aliasing, the last big issue, was tackled in C99). Rust can do everything C does, but it also has a much smarter type system backing it up and enforcing memory safety. Dynamically typed languages like Python, Ruby, Lua etc. are essentially always slower and more memory-hungry because of their intentional flexibility - to do as much as they do at runtime, they end up retaining more stuff per piece of data and paying a bigger cost to manipulate it. Luajit is an example of best-in-class technology for dynamic languages, and it's still not as fast as Go on most of the benchmark game. [0] Where Go stands in these two concerns is roughly comparable to Java or C#: it uses GC, and it has an intentionally simplistic static type system which points you towards built-in data structures, which makes it easy to work with for average-case situations, but hard or impossible to "tune up" as needs grow more complex. And if you check the benchmark game, all three are in the same window of performance, with some variance that could mostly come down to implementation detail. [0] http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=go&lang2=lua http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...
- Dewie 12y ago
  So, Go is garbage collected and seems to rely on compiler optimizations for optimizing heap allocations to stack allocations (where applicable). Meanwhile, Rust is centered around manual memory management, discourages heap allocation if you can use stack allocation, and even has (or plans to have) a library for choosing different allocators when those give better performance (which should give an inclination of at what level Rust aims for). And it leverages an existing compiler architecture for generating the native code. Your hunch/gut feeling seems to be very off.
  - SwellJoe 12y ago
    It was based on lack of knowledge about Rust. I didn't know any of those things about Rust. I assumed it was similar to Go (garbage collected, at the least). As I mentioned, I don't know a lot about either language; less about Rust. Which is why I mentioned I'd like to see a discussion about why Rust was faster.
biggest_lou 12y ago
The Rust benchmarks will become a lot more interesting (and realistic) when they don't rely so heavily on unsafe calls to C code.
- dfkf 12y ago
  Only three rust benchmarks use unsafe code, in one of them it's virtually mandatory, and in another it's just one line. On a side note, rust compiler enforces naming conventions, which is kind of cute.
  - tuxychandru 12y ago
    The reverse complement program certainly doesn't need unsafe code, but the safe rust version[1] takes 3x the execution time of the unsafe rust version[2]. By comparison the fastest Go version[3] is fairly idiomatic Go without unsafe memory management and takes just 2x the time of the unsafe rust version. Also, which benchmark did you have in mind when you said unsafe code is mandatory? [1] http://benchmarksgame.alioth.debian.org/u64q/program.php?test=revcomp&lang=rust&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... [2] http://benchmarksgame.alioth.debian.org/u64q/program.php?test=revcomp&lang=rust&id=4 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... [3] http://benchmarksgame.alioth.debian.org/u64q/program.php?test=revcomp&lang=go&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
    - dbaupp 12y ago
      That specific safe version, which, IIRC, was a basic translation of the fastest C version. I'd guess that there's other safe variations that are more idiomatic and much faster.
      - tuxychandru 12y ago
        May be a faster safe version should be contributed. The current state is that unsafe rust takes half as much time as a safe go program in this benchmark. That is not very interesting because the benefits offered by rust are being given up to perform better, for a problem that doesn't really need unsafe memory access. Same is the case with spectral norm. It is unsafe rust beating safe go there too.
anonfunction 12y ago
This lines up with my experience with the two languages as well. Usually I could get Rust to be virtually just as fast as C or C++ while Go would be roughly twice as slow. However I still prefer Go due to the quick compilation times and ease of development.
jerf 12y ago
Probably more interesting is Rust vs. C++. Rust is actually beating C++ on several benchmarks, by a comfortable margin. Go is a modern scripting language, stripped of the features that make scripting languages impossible to multithread and intrinsically slow, statically typed, and with things built on top of the multithreading. (The Perl/Python/PHP/etc series of languages is very heavy weight, huge VMs, dynamic everything, and while if you started from day one to write one of them to be threaded you could probably do it, bodging it on after the fact was virtually impossible. IMHO "dynamic everything" turned out to be a great deal more dynamic than was really necessary. But it was a worthy experiment!) Rust is a C++ replacement. Go is very fast relative to its real competition, but it is certainly not a C++ replacement. It also seems to me that Go is likely to converge on being easier to develop; I don't think Rust is going to get all of this quite for free. Both will sit on an interesting part of the bang-for-the-buck curve that is currently not well-occupied. That is, it is occupied, but it is not well occupied.
- bitbiter 12y ago
  Unfortunately the only C++ comparison is with g++, which makes me wonder how much we're actually benchmarking the llvm backend versus the gcc backend. Perhaps even more interesting is how gcc C consistently outperforms g++ C++ (and Rust, for that matter).
  - jerf 12y ago
    Yeah, usual benchmarks caveat, take with grain of salt. Still it's an interesting result. Many languages aren't even within spitting distance of C++, after all. And that's actually really good performance for a 1.0 of something like Rust; usually at this phase even a language putatively tuned for performance is still hanging around at 1/2 - 1/4 the speed of C, at least based on what I see. Rust is doing something right.
- shanemhansen 12y ago
  Please illuminate me as to how you have arrived at the conclusion go is a scripting language. It doesn't check any of the scripting language boxes I've ever heard of.
lazyjones 12y ago
Yes, LLVM is good these days. But look at the source code and decide for yourself what kind of code you'd rather read/work on. Personally, I'll stay away from Rust for the sake of my eyes: http://benchmarksgame.alioth.debian.org/u64/program.php?test=spectralnorm&lang=rust&id=3 http://benchmarksgame.alioth.debian.org/u64/program.php?test... (Go counterpart: http://benchmarksgame.alioth.debian.org/u64/program.php?test=spectralnorm&lang=go&id=1 http://benchmarksgame.alioth.debian.org/u64/program.php?test...) - Go code I've written will eventually perform better as the compiler is optimized, but optimized Rust will always be an ugly mess.
- TheHydroImpulse 12y ago
  It's highly unlikely Go will be able to compete in terms of compiler optimizations because of it's goal of fast compilation speeds. The majority of the time Rust spends compiling code is within LLVM last time I checked, because LLVM does quite a bit of optimizations. Then if you take into account the fact that Go's language features do not promote highly-performant code (GC, heap allocation, dynamic dispatching) that a few people in this thread has touched on. While better looking code is highly subjective, Rust has indeed traded off some aesthetics for safety, performance, etc... However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust.
  - lazyjones 12y ago
    > It's highly unlikely Go will be able to compete in terms of compiler optimizations because of it's goal of fast compilation speeds. For a given piece of code as written today, its compilation speed will naturally improve over time as processors get faster. Optimizing it to a certain degree becomes faster for the same reason. Therefore, assuming a fixed threshold for what constitutes "fast [enough] compilation", potential for more optimizations becomes available over time. > However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust. That's true for many languages, including PHP or Perl. The problem is: once you use these languages more, you discover that most people don't do it (for various reasons, one of them often being that they're trying to be clever).
- 12y ago
digitalzombie 12y ago
I blame it on Rob Pike saying it was a system language. He later regret it but it's too late everybody just bench Go with any system language there is out there. Go is better off as a middleware language that rival that of Node.JS (javascript) imo. Everybody see Node.JS (javascript) as somesort of web dev language in the same vein as Ruby, Python and PHP. But the web frameworks out there that I've seen are mostly incomplete or just very bare bones compare to RoR, Django, and Laravel. Express is very very barebone and you wouldn't prototype with that or do anything quick with that. You can argue that would use Node.JS for long term stuff and my counter point would be if your code have to survive for more than 6 months then use a type language. I don't believe a dynamically loose type language such as Javascript is suitable. Go would be better in this regard. I'd like to see Rust vs Ada vs C++
- TheHydroImpulse 12y ago
  > Express is very very barebone and you wouldn't prototype with that or do anything quick with that The point of the Node ecosystem is to be library-based. It's quite rare to have full-fledge frameworks dictate an environment like Rails does (and a method I personally hate). Go has the same principle afaik with it's web libraries. I'd personally rather use a dynamic language rather than a statically-typed one with a weak type system. While the former can produce more errors at times, the later is often times just too inflexible and painful to use properly.
- igouy 12y ago
  Rust & Ada & C++ are all shown on the benchmarks game website.

59 points by riccomini 12y ago

Had I been asked "which do you think is faster, on average?" I would have guessed Go. I'm not sure why but that was my gut feeling. Rust feels newer and less developed (though they are both similar in age), to me, and also more ambitious in some regards. But, this turns that on its head. Microbenchmarks are, of course, to be taken with a grain of salt, but it's still a useful data point. More useful would be a discussion of why it is so.

samnardoni 12y ago
Rust uses LLVM, which does all the optimisation. Go generates the machine code itself and its optimisation is pretty weak compared to LLVM.
- SwellJoe 12y ago
  An older version of the benchmarks discussed on the Go mailing list was done with GCCGO (which I assume is Go with a GCC backend). Given that GCC is historically ahead of LLVM on CPU optimizations (a gap that has shrunk in recent years), I'm guessing that's not a complete answer. But, if it is the primary source, it would tell me that Go will close the gap as the compiler becomes more advanced and takes advantage of more CPU optimization features. Also, it's an interesting difference that Rust is an LLVM language while Go is compiled to native code directly; probably not from a performance perspective (at least not in the long run), but from a development perspective...is it easier or harder to develop new language features on LLVM or a native compiler? https://groups.google.com/forum/#!topic/golang-nuts/NSPcEqhe-8I https://groups.google.com/forum/#!topic/golang-nuts/NSPcEqhe...
  - dbaupp 12y ago
    Note: despite the "VM" in the name LLVM is a native compiler: the rust compiler constructs the appropriate internal representation to LLVM and passes it to LLVM for optimisation and native code generation. There's not really a fundamental difference between this and writing the code generation step in pure Rust other than the latter missing out on all the benefits (speed, architecture support etc) of LLVM. That is to say: there's not much difference for difficulty of developing new language features, but avoiding LLVM makes it harder to develop new fast language features.
mamcx 12y ago
Exist a well rounded samples for benchmark compilers?, I mean, not just micro, but more complete?
wycats 12y ago
A design goal of Rust is to target the performance of well-written, safe C++. It doesn't (today) even ship with a garbage collector, discourages heap allocation (which is your only option in normal Go), and avoids dynamic dispatch in the vast majority of cases. In contrast, idiomatic Go code is garbage collected, heap allocation heavy, and dynamic dispatch heavy. That isn't always going to mean that Rust code is faster, but for benchmark games like this, when Rust is slower it almost always means that the benchmark is wrong.
- SwellJoe 12y ago
  I read an article recently about memory in Go (the "why is my go program 138GB!?" article), which was enlightening and also weird. I don't have any experience with either language, but have plans to learn a smattering of both in 2015. As for dynamic dispatch...does Rust not support it, or is there some language construct that allows solving the problems dynamic dispatch solves without imposing annoying limitations or needless verbosity? And, aren't there fast implementations of dynamic dispatch?
  - steveklabnik 12y ago
    Rust supports both. You might enjoy reading http://programmers.stackexchange.com/a/247313 http://programmers.stackexchange.com/a/247313
  - wycats 12y ago
    > As for dynamic dispatch...does Rust not support it, or is there some language construct that allows solving the problems dynamic dispatch solves without imposing annoying limitations or needless verbosity? Rust supports dynamic dispatch if you truly need it, but the normal approach is to use trait bounds, which the compiler expands when used. Here's an example: fn main() { let r = MemReader::new("hello world\n".as_bytes()); get_line(&r); } fn get_line<R: Buffer>(r: &R) -> IoResult<String> { r.read_line() } In this very simple example, the `get_line` function takes any value that implements the `Buffer` trait, which provides the `read_line` method. When `get_line` is called inside of `main`, the compiler creates a special version of `get_line` that takes a `MemReader`, and dispatches to its implementation of `read_line` statically. In practice, this feels a lot like dynamic dispatch, but using trait bounds always results in static dispatch in practice. Also, in this example, the `MemReader` is stack-allocated, and lent to the `get_line` method. In very rare cases, you may want dynamic dispatch. For example, imagine you have an array of Buffers, and want to read a line from each of them. In this case, you use a "trait object" (a `Box<Buffer>`), which moves the object to the heap and allows dynamic dispatch. In practice, I have written many thousands of lines of production Rust code and have only encountered a need for trait objects a handful of times. This means that idiomatic, normal Rust code is stack-allocated and statically dispatched. The verbosity of trait bounds has decreased more and more over time, and my favorite proposal (by aturon) for making it pretty close to maximally ergonomic is: fn main() { let r = MemReader::new("hello world\n".as_bytes()); get_line(&r); } fn get_line(r: &impl Reader) -> IoResult<String> { r.read_line() } I hope this lands as new syntax after 1.0 :)
pdpi 12y ago
There's not even a chance at a competition, because of their respective design goals. Go is explicitly meant to have _really_ fast compilation times, which precludes the Go compilers from any expensive optimisations. Rust, on the other hand, has an explicit goal of being as fast as idiomatic/safe C/C++ while removing the burden of writing the safety yourself, so it really _has_ to be fast.
chipsy 12y ago
You can typically predict performance behaviors across a whole language based on memory allocation patterns and the type system. If automatic memory management is built in, that adds some overhead to most allocation situations(and encourages an architecture that exploits easy allocation - e.g. Java libraries where everything you do involves a new()). There are differences between garbage collection(mark-and-sweep) and reference counting as well; an RC system is "pay for what you allocate" with predictable scaling, making it more appropriate to employ for hitting real-time deadlines, however, the state-of-the-art in generational mark-and-sweep GC does better for average case throughput. Or to put it another way, if you have a single batch process that everything goes through, you can usually count on a GC system doing it faster than a RC equivalent. But if you want to run several things concurrently and tally results, or you are running an interactive app and care about getting your latency numbers down, the pauses involved in GC may be more problematic to you. (The semantic downside of RC, which has also made a lot of languages avoid it, is its inability to deal with circular data references.) Of course, manually managed memory lets you design any allocation strategy you want, and so it can let you blow away automatically managed systems on microbenchmarks like these - stuff that starts mattering in the real world only after you've scaled up near to the constraints of the target hardware and any overhead is a Really Big Problem. There's definitely some more experimental automatic technology out there that "breaks the rules," but in terms of what you see in today's production environments, you can start estimating performance characteristics just by knowing what type of allocation is being done. The other big issue, of course, is the type system. The design of the type system determines the constraints and difficulty of automated optimizations; classically, Fortran was one of the best languages for low-level optimization because it made things very easy for the compiler, and offloaded many considerations on the programmer. Today C has grown into a roughly equivalent space(pointer aliasing, the last big issue, was tackled in C99). Rust can do everything C does, but it also has a much smarter type system backing it up and enforcing memory safety. Dynamically typed languages like Python, Ruby, Lua etc. are essentially always slower and more memory-hungry because of their intentional flexibility - to do as much as they do at runtime, they end up retaining more stuff per piece of data and paying a bigger cost to manipulate it. Luajit is an example of best-in-class technology for dynamic languages, and it's still not as fast as Go on most of the benchmark game. [0] Where Go stands in these two concerns is roughly comparable to Java or C#: it uses GC, and it has an intentionally simplistic static type system which points you towards built-in data structures, which makes it easy to work with for average-case situations, but hard or impossible to "tune up" as needs grow more complex. And if you check the benchmark game, all three are in the same window of performance, with some variance that could mostly come down to implementation detail. [0] http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=go&lang2=lua http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...
Dewie 12y ago
So, Go is garbage collected and seems to rely on compiler optimizations for optimizing heap allocations to stack allocations (where applicable). Meanwhile, Rust is centered around manual memory management, discourages heap allocation if you can use stack allocation, and even has (or plans to have) a library for choosing different allocators when those give better performance (which should give an inclination of at what level Rust aims for). And it leverages an existing compiler architecture for generating the native code. Your hunch/gut feeling seems to be very off.
- SwellJoe 12y ago
  It was based on lack of knowledge about Rust. I didn't know any of those things about Rust. I assumed it was similar to Go (garbage collected, at the least). As I mentioned, I don't know a lot about either language; less about Rust. Which is why I mentioned I'd like to see a discussion about why Rust was faster.

biggest_lou 12y ago

The Rust benchmarks will become a lot more interesting (and realistic) when they don't rely so heavily on unsafe calls to C code.

dfkf 12y ago
Only three rust benchmarks use unsafe code, in one of them it's virtually mandatory, and in another it's just one line. On a side note, rust compiler enforces naming conventions, which is kind of cute.
- tuxychandru 12y ago
  The reverse complement program certainly doesn't need unsafe code, but the safe rust version[1] takes 3x the execution time of the unsafe rust version[2]. By comparison the fastest Go version[3] is fairly idiomatic Go without unsafe memory management and takes just 2x the time of the unsafe rust version. Also, which benchmark did you have in mind when you said unsafe code is mandatory? [1] http://benchmarksgame.alioth.debian.org/u64q/program.php?test=revcomp&lang=rust&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... [2] http://benchmarksgame.alioth.debian.org/u64q/program.php?test=revcomp&lang=rust&id=4 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... [3] http://benchmarksgame.alioth.debian.org/u64q/program.php?test=revcomp&lang=go&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
  - dbaupp 12y ago
    That specific safe version, which, IIRC, was a basic translation of the fastest C version. I'd guess that there's other safe variations that are more idiomatic and much faster.
    - tuxychandru 12y ago
      May be a faster safe version should be contributed. The current state is that unsafe rust takes half as much time as a safe go program in this benchmark. That is not very interesting because the benefits offered by rust are being given up to perform better, for a problem that doesn't really need unsafe memory access. Same is the case with spectral norm. It is unsafe rust beating safe go there too.

anonfunction 12y ago

This lines up with my experience with the two languages as well. Usually I could get Rust to be virtually just as fast as C or C++ while Go would be roughly twice as slow. However I still prefer Go due to the quick compilation times and ease of development.

jerf 12y ago

Probably more interesting is Rust vs. C++. Rust is actually beating C++ on several benchmarks, by a comfortable margin. Go is a modern scripting language, stripped of the features that make scripting languages impossible to multithread and intrinsically slow, statically typed, and with things built on top of the multithreading. (The Perl/Python/PHP/etc series of languages is very heavy weight, huge VMs, dynamic everything, and while if you started from day one to write one of them to be threaded you could probably do it, bodging it on after the fact was virtually impossible. IMHO "dynamic everything" turned out to be a great deal more dynamic than was really necessary. But it was a worthy experiment!) Rust is a C++ replacement. Go is very fast relative to its real competition, but it is certainly not a C++ replacement. It also seems to me that Go is likely to converge on being easier to develop; I don't think Rust is going to get all of this quite for free. Both will sit on an interesting part of the bang-for-the-buck curve that is currently not well-occupied. That is, it is occupied, but it is not well occupied.

bitbiter 12y ago
Unfortunately the only C++ comparison is with g++, which makes me wonder how much we're actually benchmarking the llvm backend versus the gcc backend. Perhaps even more interesting is how gcc C consistently outperforms g++ C++ (and Rust, for that matter).
- jerf 12y ago
  Yeah, usual benchmarks caveat, take with grain of salt. Still it's an interesting result. Many languages aren't even within spitting distance of C++, after all. And that's actually really good performance for a 1.0 of something like Rust; usually at this phase even a language putatively tuned for performance is still hanging around at 1/2 - 1/4 the speed of C, at least based on what I see. Rust is doing something right.
shanemhansen 12y ago
Please illuminate me as to how you have arrived at the conclusion go is a scripting language. It doesn't check any of the scripting language boxes I've ever heard of.

lazyjones 12y ago

Yes, LLVM is good these days. But look at the source code and decide for yourself what kind of code you'd rather read/work on. Personally, I'll stay away from Rust for the sake of my eyes: http://benchmarksgame.alioth.debian.org/u64/program.php?test=spectralnorm&lang=rust&id=3 http://benchmarksgame.alioth.debian.org/u64/program.php?test... (Go counterpart: http://benchmarksgame.alioth.debian.org/u64/program.php?test=spectralnorm&lang=go&id=1 http://benchmarksgame.alioth.debian.org/u64/program.php?test...) - Go code I've written will eventually perform better as the compiler is optimized, but optimized Rust will always be an ugly mess.

TheHydroImpulse 12y ago
It's highly unlikely Go will be able to compete in terms of compiler optimizations because of it's goal of fast compilation speeds. The majority of the time Rust spends compiling code is within LLVM last time I checked, because LLVM does quite a bit of optimizations. Then if you take into account the fact that Go's language features do not promote highly-performant code (GC, heap allocation, dynamic dispatching) that a few people in this thread has touched on. While better looking code is highly subjective, Rust has indeed traded off some aesthetics for safety, performance, etc... However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust.
- lazyjones 12y ago
  > It's highly unlikely Go will be able to compete in terms of compiler optimizations because of it's goal of fast compilation speeds. For a given piece of code as written today, its compilation speed will naturally improve over time as processors get faster. Optimizing it to a certain degree becomes faster for the same reason. Therefore, assuming a fixed threshold for what constitutes "fast [enough] compilation", potential for more optimizations becomes available over time. > However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust. That's true for many languages, including PHP or Perl. The problem is: once you use these languages more, you discover that most people don't do it (for various reasons, one of them often being that they're trying to be clever).
12y ago

digitalzombie 12y ago

I blame it on Rob Pike saying it was a system language. He later regret it but it's too late everybody just bench Go with any system language there is out there. Go is better off as a middleware language that rival that of Node.JS (javascript) imo. Everybody see Node.JS (javascript) as somesort of web dev language in the same vein as Ruby, Python and PHP. But the web frameworks out there that I've seen are mostly incomplete or just very bare bones compare to RoR, Django, and Laravel. Express is very very barebone and you wouldn't prototype with that or do anything quick with that. You can argue that would use Node.JS for long term stuff and my counter point would be if your code have to survive for more than 6 months then use a type language. I don't believe a dynamically loose type language such as Javascript is suitable. Go would be better in this regard. I'd like to see Rust vs Ada vs C++

TheHydroImpulse 12y ago
> Express is very very barebone and you wouldn't prototype with that or do anything quick with that The point of the Node ecosystem is to be library-based. It's quite rare to have full-fledge frameworks dictate an environment like Rails does (and a method I personally hate). Go has the same principle afaik with it's web libraries. I'd personally rather use a dynamic language rather than a statically-typed one with a weak type system. While the former can produce more errors at times, the later is often times just too inflexible and painful to use properly.
igouy 12y ago
Rust & Ada & C++ are all shown on the benchmarks game website.