Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust programs versus Go

benchmarksgame-team.pages.debian.net

Post reply on HN
Print view View original

141–150 of 209 posts

Re: Rust programs versus Go

#141

Post by kevin_b_er »

cdoxsey wrote: post #41

These benchmarks have many flaws. Consider this thread: https://www.reddit.com/r/golang/comments/51mhzv/on_the_binar... The binary-trees benchmark would fare significantly better in Go if it were allowed to use an arena allocator like other implementations. But its not. This despite the fact that the Rust version literally uses one: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . I guess because its…

So, we're basically looking at the difference between malloc and an arena allocator?

Re: Rust programs versus Go

#142

Post by kibwen »

What's the point of posting this? Rust and Go are only "competitors" in the sense that every language competes with every other. You might as well post the page comparing Go to Fortran or Rust to Clojure. Rust and Go have different objectives, philosophies, tradeoffs, and intended domains. Posts like this seem like they serve no purpose other than to inspire flamewars. And I say this as a heavy Rust user, so don't think that I'm embarrassed by these microbenchmarks. :P

Re: Rust programs versus Go

#143

Post by Aissen »

burntsushi wrote: post #137
Aissen wrote: post #20

Anyone has tried modifying the go regex benchmark to use https://github.com/BurntSushi/rure-go ? It seems to use a library that isn't even on github anymore.

I had fun with this: [andrew@Cheetah benchgame] time bench-native For comparison, this is the timing for the Rust program, unchanged from the benchmark site: $ time ./target/release/bench-rust-regex See https://gist.github.com/BurntSushi/9d35258444fda83de208d31fd... for source code and full results. And no, I won't submit this myself, although I would find it absolutely hilarious if someone did and managed to get it…

Awesome work, thanks !

Re: Rust programs versus Go

#144

Post by pcwalton »

pron wrote: post #77
Tuna-Fish wrote: post #62

Earlier quoted context omitted.

Explanations for the few largest offenders: 1. regex-redux Rust has it's own regexp engine, that lacks a few of the bells and whistles of PCRE, but is much faster than it. (And has no sheer perfomance cliffs where a carefully crafted target string or search expression can DOS the app.) Also, I think the rust implementation can do less copying. GO just uses PCRE. (Which is weird, isn't RE2 a google project?) 2. binary…

> The GO implementation has to use the platform allocator. So does the Java implementation, and still it fares much (3x) better than Go.

Because the Java GC has better throughput than the Go GC. The Go GC makes enormous throughput sacrifices by prioritizing latency above all else.

Re: Rust programs versus Go

#145

Post by PyroLagus »

stunt wrote: post #118

Don't forget GO is not low level langauge. it is fast because it is compiled. Not sure why there is argument against it. I thought it is obvious for everyone. Rust is lower level, gives less abstractions, and designed for performance. Rust performance is comparable with C and C++. That was the whole idea.

I wouldn't say that it gives less abstractions. The Rust devs are obviously careful about adding abstractions that add a performance cost, but Rust has quite a few abstractions that Go doesn't have; generics being the most notable one.

Re: Rust programs versus Go

#146

Post by pcwalton »

burntsushi wrote: post #89
Tuna-Fish wrote: post #62

Earlier quoted context omitted.

Explanations for the few largest offenders: 1. regex-redux Rust has it's own regexp engine, that lacks a few of the bells and whistles of PCRE, but is much faster than it. (And has no sheer perfomance cliffs where a carefully crafted target string or search expression can DOS the app.) Also, I think the rust implementation can do less copying. GO just uses PCRE. (Which is weird, isn't RE2 a google project?) 2. binary…

With respect to your comments about regex, could you please share with me where you got your information? I would love to know so that I can go bug whoever it is to correct it. > Rust has it's own regexp engine, that lacks a few of the bells and whistles of PCRE, but is much faster than it. The only true part of this is that Rust's regex engine lacks many features found in PCRE. Mostly, these features revolve around…

I love how incredibly fair your posts always are. I think I have learned something from every single one. :)

Re: Rust programs versus Go

#147

Post by riku_iki »

cdoxsey wrote: post #41

These benchmarks have many flaws. Consider this thread: https://www.reddit.com/r/golang/comments/51mhzv/on_the_binar... The binary-trees benchmark would fare significantly better in Go if it were allowed to use an arena allocator like other implementations. But its not. This despite the fact that the Rust version literally uses one: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . I guess because its…

> I guess because its not in the stdlib in Go?

I think the premise of these specific benchmark is to use language idiomatic approaches instead of hacky optimizations. Is arena allocator idiomatic for go? What library people usually use? I tried to do google search, and found this one, but it is last updated 3 years ago.. https://github.com/couchbase/go-slab

Re: Rust programs versus Go

#148

Post by littlestymaar »

lmm wrote: post #65
cmyr wrote: post #10

Nothing in these results should really surprise anyone. Go is a good tool for writing networking services, but it is not (and does not intend to be) a systems language. For another perspective, look at Go versus Python: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Go is a compiled managed language; unsurprisingly performance is similar to Java or C# (or, say, Haskell or OCaml). There was a lot of frankly dishonest promotion of it as a C-like systems language for performance, but reality wins out in the end.

Being “compiled” (which in reality means “statically-compiled”) doesn't give you magical gains you know. It can even be the opposite, since you can't benefit from JIT optimizations.

What makes C, C++ or Rust efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations. Go's compiler is way less aggressive with optimization because they wants to keep the compile-time low (which is probably a good idea in their niche) and because it has been much less of a focus than for LLVM or Gcc.

Also, the lack of generics and the pervasive use of dynamic dispatch (with interfaces) also prevent many optimization but it keeps compilation fast, which is what Go developers want. (Please note that this is not an argument in favor of Go developers not adding generics to the language, they could totally add generics but keep the dynamic dispatch to keep the compile-time as it is right now).

Re: Rust programs versus Go

#149

Post by steveklabnik »

vanderZwan wrote: post #111
notheguyouthink wrote: post #96

Earlier quoted context omitted.

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 m…

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

1. long ago, we used to have green threads and a runtime

2. we decided to eschew the runtime, and therefore, the green threads.

3. Since then, various libraries have implemented green threads in various ways

4. Tokio is basically green threads today. It really depends on what you mean exactly by "green threads".; but it schedules N tasks on M OS threads, so...

Re: Rust programs versus Go

#150

Post by steveklabnik »

Thaxll wrote: post #119
giancarlostoro wrote: post #50

Earlier quoted context omitted.

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/ and go from there, then I can use rustup to upd…

You mention tooling and IDE where Go is better than Rust in that space and as for Cargo just use go dep problem solved.

What tooling do you prefer in Go and why? Just curious!
Post reply on HN