5 ms·

Oh no, not The Benchmarks Game again :( This whole thing is meaningless and deeply flawed. The sources of the various solutions vary a lot in quality: differe

Oh no, not The Benchmarks Game again :( This whole thing is meaningless and deeply flawed. The sources of the various solutions vary a lot in quality: different libraries are used, different settings (in Go vs Java the use of threads is almost never the same). I suspect the only true end of this benchmarking exercise is to make people comment vigorously on HN and similar forms. Can we stop posting them?

vonseel 8y ago
> suspect the only true end of this benchmarking exercise is to make people comment vigorously on HN and similar forms. I suspect you are right and some of the posters suffer from “watching the likes roll-in” addiction
bananarepdev 8y ago
Probably going to get downvoted for that, but could you recommend me some similar forums? :)
- dx034 8y ago
  Reddit can be decent IMO (e.g. reddit.com/r/golang)
chatmasta 8y ago
I’m the OP. I figured this post would either get tons of upvotes or flagged off the first page. The title really is a firebomb on HN lol. But honestly I find it genuinely interesting. I’m planning to take some time to learn either rust or go this month, so comparisons like this are helpful for me. And I also appreciate the contrarian comments and discussion of the merits (or lack thereof) of the benchmarks.
- giancarlostoro 8y ago
  I used to like Go a bit, but never did a full blown application in it, just did enough to get a feel of it. Having tried Rust recently (after not liking the idea of not having classes like in Go) I have to say I prefer Rust for several reasons. For starters the tooling for Rust is well done. If I want to install Rust on any machine I'm on I just go to https://rustup.rs/ https://rustup.rs/ and go from there, then I can use rustup to update my tooling or add features to the compiled. The other thing is the wealth of packages[0] that expand upon Cargo (Rusts build system and package manager) namely the cargo-deb package which lets me build my Rust projects directly into a Debian package. Continuing on about tooling I have to mention that for IDE's / Text Editors: CLion w/ Rust Plugin is fantastic, but if you want something fully free the VS Code plugin is also amazing for Rust. There's a great effort towards building the Rust Language Server, which thanks to Microsoft is a generic spec that once implemented for one language can be used by any editor / IDE that supports langserver[1]. I will say depending on what you want to do with Rust there can be a bit of a learning curve. I'm still just bleeding my way through some parts because I don't know what everything means in Rust just enough to try different things. I will say Rust is nowhere near where it could be, but it's at a stage where I think it's definitely usable. They definitely took their time to make sure they got things right, and they got plenty right. [0]: https://crates.io/ https://crates.io/ [1]: http://langserver.org/ http://langserver.org/
  - Thaxll 8y ago
    You mention tooling and IDE where Go is better than Rust in that space and as for Cargo just use go dep problem solved.
    - deleted 8y ago
      [deleted]
    - steveklabnik 8y ago
      What tooling do you prefer in Go and why? Just curious!
    - senorsmile 8y ago
      Honestly, the tooling in go seems very poor to me. There are lots of potential solutions, none of which remotely compare to the efficiency and ease of use of cargo. Golang needs a project independent manager, a la carton,bundler, or pipenv (although cargo is the best imho).
- notheguyouthink 8y ago
  I really, really like Rust. Yet, I use Go. This is mainly do to firstly, Go just fits way way better for my shop. The transition from my fellow employees from Python to Go is pretty straight forward. Secondly, Go is just nicely setup for ease. I had so much hell in Rust cross compiling a simple https server.. it was mind numbing. It might be better now, but I was shocked at how difficult it was. Finally, Go is just more nice to write in when you're.. well, writing it out. I guess I tend to write as I think about data structures, abstractions, general design. I don't draw it ahead of time or w/e, I just write code. Go is very minimal, and is pretty forgiving to quick rewrites/etc. In Rust I found myself writing myself into a corner constantly when all I was trying to do was get an idea out of my head. With that said, I vastly preferred Rust's feeling of knowing exactly what my program is doing. No question on if something is nil or not, you know it is or isn't (or know it's unknown haha). I think for me, in another 2 years I'll push again for Rust > Go in my shop as I imagine the Rust tooling will have improved to the point where it's easier and more quick to write things. Rust was experiencing a lot of cargo package churn, I spent hours debugging which packages worked together, it was a headache. Even understanding errors was a bit of a headache, despite the compiler trying really hard. Rust is making great strides though, and even though I use Go to get shit done, Rust is probably my favorite language.. that I don't use heh. edit: Oh yea, and green threads, god do I wish Rust had green threads. I found Rust to be similar to Go in multithreading ergonomics, but I couldn't use them in the same manner as with Go - ie, fire off as many as I want. There are several libraries in development that should take care of this though, I believe.
  - vanderZwan 8y ago
    > Oh yea, and green threads, god do I wish Rust had green threads. They still don't? I thought they were working on that years ago, no?
    - notheguyouthink 8y ago
      They had green threads, but removed it. To my knowledge, there are multiple libraries that effectively implement green threads, but it's still a work in progress. Might be production ready, not sure, but I believe at the very least the ergonomics are a work in progress.
- skywhopper 8y ago
  I disagree that the comparison as presented on this page is useful for you. If there were any context or discussion of the results and what they mean in terms of differences between the languages, then maybe it could be. But raw benchmarks collected with no indication of why or how is not. In the regex test, for example, all the patterns are very similar to each other and don’t really cover the breadth of what a regex engine can do (specific patterns may influence the results greatly—there are some very simple patterns that send the default Java regex engine into O(n^n) fits). And regex in particular is a very well understood problem space. So something very interesting is going on there for the golang result to be so far off. What is happening? Well, we’ll never know from this page. Oh well?
  - chatmasta 8y ago
    Agreed... which is why I posted it here and it got 80+ comments. So there is a discussion now!
  - igouy 8y ago
    >> Well, we’ll never know from this page. Apparently, you now know that there's "something very interesting" to investigate! So, investigate?
- PopsiclePete 8y ago
  No reason to learn Rust or Go - learn Rust and Go. I use Go for most "network service" type stuff at my job. I would probably not choose Rust for those, even if I was as comfortable with it as I was with Go (which I'm not, since Go is much, much simpler). There's many variables when considering what language to pick for a problem and if speed was the only thing we cared about, we'd just do raw assembly always.
  - steveklabnik 8y ago
    We're even seeing production deployments that combine the two directly; Conduit and Dropbox both come to mind.
some_account 8y ago
Benchmarks are important actually. Maybe they are not 100% accurate but they do tell you that rust is faster than go. Since rust is also more complex than go, you have to decide if it's worth complexity and learning curve for the speed. Without benchmarks, we all would use python for everything right? :)
- _ph_ 8y ago
  Well, no. Some of the presented benchmarks prevent the Go solution to be as efficient as the Rust one by their rules, e.g. prohibiting object pools in Go, but not in other languages. Same with hash tables. They benchmark the default Go hash tables vs. custom implemented ones for the benchmark in C.
  - seba_dos1 8y ago
    Which, at least for hash tables, seems completely reasonable and representative of most actual experiences with both languages?
    - _ph_ 8y ago
      No. Standard libraries are a good thing, but if you want to write performant code, you definitely should consider a more specific implementation which is tuned to your actual problem. This is good practise in any programming language. But the rules of this benchmark page explicitly prohibit that, so languages, which don't have hash tables in their "standard" library have a strong advantage, which isn't a good representation of the speeds of well writting programs in those languages.
      - seba_dos1 8y ago
        In terms of performance, languages which don't have has tables in their standard library have an advantage in real life too, not just in the benchmark. While what you say is true, in great majority of the real life cases, if there's hash table implementation in the library, the developer will use that. If there's none, then they will start looking for one, making it more likely that they will choose a more fine-tuned to their needs implementation than if they already had generic one provided in the standard library.
igouy 8y ago
>> in Go vs Java the use of threads is almost never the same Seems like you might be suggesting the Go programs don't use multicore but the Java programs they are compared against do use multicore, or vice versa, or …? Currently just 1 comparison (reverse-complement) shows a sequential Go program and a threaded Java program.

vonseel 8y ago

> suspect the only true end of this benchmarking exercise is to make people comment vigorously on HN and similar forms. I suspect you are right and some of the posters suffer from “watching the likes roll-in” addiction

bananarepdev 8y ago

Probably going to get downvoted for that, but could you recommend me some similar forums? :)

dx034 8y ago
Reddit can be decent IMO (e.g. reddit.com/r/golang)

chatmasta 8y ago

I’m the OP. I figured this post would either get tons of upvotes or flagged off the first page. The title really is a firebomb on HN lol. But honestly I find it genuinely interesting. I’m planning to take some time to learn either rust or go this month, so comparisons like this are helpful for me. And I also appreciate the contrarian comments and discussion of the merits (or lack thereof) of the benchmarks.

giancarlostoro 8y ago
I used to like Go a bit, but never did a full blown application in it, just did enough to get a feel of it. Having tried Rust recently (after not liking the idea of not having classes like in Go) I have to say I prefer Rust for several reasons. For starters the tooling for Rust is well done. If I want to install Rust on any machine I'm on I just go to https://rustup.rs/ https://rustup.rs/ and go from there, then I can use rustup to update my tooling or add features to the compiled. The other thing is the wealth of packages[0] that expand upon Cargo (Rusts build system and package manager) namely the cargo-deb package which lets me build my Rust projects directly into a Debian package. Continuing on about tooling I have to mention that for IDE's / Text Editors: CLion w/ Rust Plugin is fantastic, but if you want something fully free the VS Code plugin is also amazing for Rust. There's a great effort towards building the Rust Language Server, which thanks to Microsoft is a generic spec that once implemented for one language can be used by any editor / IDE that supports langserver[1]. I will say depending on what you want to do with Rust there can be a bit of a learning curve. I'm still just bleeding my way through some parts because I don't know what everything means in Rust just enough to try different things. I will say Rust is nowhere near where it could be, but it's at a stage where I think it's definitely usable. They definitely took their time to make sure they got things right, and they got plenty right. [0]: https://crates.io/ https://crates.io/ [1]: http://langserver.org/ http://langserver.org/
- Thaxll 8y ago
  You mention tooling and IDE where Go is better than Rust in that space and as for Cargo just use go dep problem solved.
  - deleted 8y ago
    [deleted]
  - steveklabnik 8y ago
    What tooling do you prefer in Go and why? Just curious!
  - senorsmile 8y ago
    Honestly, the tooling in go seems very poor to me. There are lots of potential solutions, none of which remotely compare to the efficiency and ease of use of cargo. Golang needs a project independent manager, a la carton,bundler, or pipenv (although cargo is the best imho).
notheguyouthink 8y ago
I really, really like Rust. Yet, I use Go. This is mainly do to firstly, Go just fits way way better for my shop. The transition from my fellow employees from Python to Go is pretty straight forward. Secondly, Go is just nicely setup for ease. I had so much hell in Rust cross compiling a simple https server.. it was mind numbing. It might be better now, but I was shocked at how difficult it was. Finally, Go is just more nice to write in when you're.. well, writing it out. I guess I tend to write as I think about data structures, abstractions, general design. I don't draw it ahead of time or w/e, I just write code. Go is very minimal, and is pretty forgiving to quick rewrites/etc. In Rust I found myself writing myself into a corner constantly when all I was trying to do was get an idea out of my head. With that said, I vastly preferred Rust's feeling of knowing exactly what my program is doing. No question on if something is nil or not, you know it is or isn't (or know it's unknown haha). I think for me, in another 2 years I'll push again for Rust > Go in my shop as I imagine the Rust tooling will have improved to the point where it's easier and more quick to write things. Rust was experiencing a lot of cargo package churn, I spent hours debugging which packages worked together, it was a headache. Even understanding errors was a bit of a headache, despite the compiler trying really hard. Rust is making great strides though, and even though I use Go to get shit done, Rust is probably my favorite language.. that I don't use heh. edit: Oh yea, and green threads, god do I wish Rust had green threads. I found Rust to be similar to Go in multithreading ergonomics, but I couldn't use them in the same manner as with Go - ie, fire off as many as I want. There are several libraries in development that should take care of this though, I believe.
- vanderZwan 8y ago
  > Oh yea, and green threads, god do I wish Rust had green threads. They still don't? I thought they were working on that years ago, no?
  - notheguyouthink 8y ago
    They had green threads, but removed it. To my knowledge, there are multiple libraries that effectively implement green threads, but it's still a work in progress. Might be production ready, not sure, but I believe at the very least the ergonomics are a work in progress.
skywhopper 8y ago
I disagree that the comparison as presented on this page is useful for you. If there were any context or discussion of the results and what they mean in terms of differences between the languages, then maybe it could be. But raw benchmarks collected with no indication of why or how is not. In the regex test, for example, all the patterns are very similar to each other and don’t really cover the breadth of what a regex engine can do (specific patterns may influence the results greatly—there are some very simple patterns that send the default Java regex engine into O(n^n) fits). And regex in particular is a very well understood problem space. So something very interesting is going on there for the golang result to be so far off. What is happening? Well, we’ll never know from this page. Oh well?
- chatmasta 8y ago
  Agreed... which is why I posted it here and it got 80+ comments. So there is a discussion now!
- igouy 8y ago
  >> Well, we’ll never know from this page. Apparently, you now know that there's "something very interesting" to investigate! So, investigate?
PopsiclePete 8y ago
No reason to learn Rust or Go - learn Rust and Go. I use Go for most "network service" type stuff at my job. I would probably not choose Rust for those, even if I was as comfortable with it as I was with Go (which I'm not, since Go is much, much simpler). There's many variables when considering what language to pick for a problem and if speed was the only thing we cared about, we'd just do raw assembly always.
- steveklabnik 8y ago
  We're even seeing production deployments that combine the two directly; Conduit and Dropbox both come to mind.

some_account 8y ago

Benchmarks are important actually. Maybe they are not 100% accurate but they do tell you that rust is faster than go. Since rust is also more complex than go, you have to decide if it's worth complexity and learning curve for the speed. Without benchmarks, we all would use python for everything right? :)

_ph_ 8y ago
Well, no. Some of the presented benchmarks prevent the Go solution to be as efficient as the Rust one by their rules, e.g. prohibiting object pools in Go, but not in other languages. Same with hash tables. They benchmark the default Go hash tables vs. custom implemented ones for the benchmark in C.
- seba_dos1 8y ago
  Which, at least for hash tables, seems completely reasonable and representative of most actual experiences with both languages?
  - _ph_ 8y ago
    No. Standard libraries are a good thing, but if you want to write performant code, you definitely should consider a more specific implementation which is tuned to your actual problem. This is good practise in any programming language. But the rules of this benchmark page explicitly prohibit that, so languages, which don't have hash tables in their "standard" library have a strong advantage, which isn't a good representation of the speeds of well writting programs in those languages.
    - seba_dos1 8y ago
      In terms of performance, languages which don't have has tables in their standard library have an advantage in real life too, not just in the benchmark. While what you say is true, in great majority of the real life cases, if there's hash table implementation in the library, the developer will use that. If there's none, then they will start looking for one, making it more likely that they will choose a more fine-tuned to their needs implementation than if they already had generic one provided in the standard library.

igouy 8y ago

>> in Go vs Java the use of threads is almost never the same Seems like you might be suggesting the Go programs don't use multicore but the Java programs they are compared against do use multicore, or vice versa, or …? Currently just 1 comparison (reverse-complement) shows a sequential Go program and a threaded Java program.