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

111–120 of 209 posts

Re: Rust programs versus Go

#111

Post by vanderZwan »

notheguyouthink wrote: post #96
chatmasta wrote: post #46

Earlier quoted context omitted.

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.

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?

Re: Rust programs versus Go

#112

Post by weberc2 »

jerf wrote: post #97
weavie wrote: post #13

Earlier quoted context omitted.

Go seems to perform really poorly in the regex-redux. Against both Node and Python Go is way faster (as one would expect) apart from with the regex-redux.. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Does Go just suck with it's regex performance? Would this be easy to fix by just pulling in a C regex library?

I disagree with the people saying the benchmarks game is useless. It mostly seems to conform to my own experiences with the various languages involved. The exception is the regex benchmark, which has little to do with the languages and everything to do with the regex library used by the language. If the dynamic scripting languages were required to use regex engines implemented in pure Python/Perl/PHP/JS, their perfor…

> I disagree with the people saying the benchmarks game is useless. It mostly seems to conform to my own experiences with the various languages involved.

I think it can only tell you about the performance cieling, and even then it can't tell you that for languages like Go where fairly obvious optimizations (like arenas) are prohibited while all manner of clever tricks are permitted for other languages.

Your remarks on performance comparisons were really insightful.

Re: Rust programs versus Go

#113

Post by pjmlp »

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.

Given the way it is being used in Fuchsia for writing critical system components like TPC/IP, WLAN, disk management, update infrastructure, it wasn't really dishonest.

C code in the 80's was about 80% inline Assembly on 16 bit machines, so surely there is plenty of room to improve Go's optimizer if they so wish.

Of course Go will never fit into those PIC micro-controllers with 16 KB of RAM.

Re: Rust programs versus Go

#114

Post by pjmlp »

logicallee wrote: post #28
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/...

to be fair, it was explicitly designed to be a systems language, and its specification says "Go is a general-purpose language designed with systems programming in mind." This should be removed, and I would say that it gave up on its design goal of being a systems language.

The TPC/IP, WLAN, disk management, system update stacks in Fuchsia sound very like systems programming to me.

Re: Rust programs versus Go

#115

Post by notheguyouthink »

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?

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.

Re: Rust programs versus Go

#116

Post by pjmlp »

notheguyouthink wrote: post #99
egnehots wrote: post #4

simplicity source brain load Rust 95% Go 23%

Sidenote, appending to that list, my NodeJS "brain load" was insane. When I switched from Node -> Go ages ago it was night and day. Funnily, in some scenarios, I find Rust to be less of a brain load than Go. In others, Rust is way way worse. As I mentioned in another post, we use Go to get shit done. I hope Rust can take that mantel some day.

I try to get shit done, but end up spending my time writing code templates for //go:generate.

Re: Rust programs versus Go

#117

Post by jimmy1 »

flavio81 wrote: post #91
egnehots wrote: post #4

simplicity source brain load Rust 95% Go 23%

more benchmarks source generics Rust 100% Go 0% source if err!=nil return { nil, err }; Rust 0% Go 100% source undeserved hype Rust 100% Go 100%

source: good generics implementations

Haskell: 100%

All Other Languages: 0%

source: flawed generics implementations

Haskell: 0%

All Other Languages: 100%

Re: Rust programs versus Go

#118

Post by stunt »

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.

Re: Rust programs versus Go

#119

Post by Thaxll »

giancarlostoro wrote: post #50
chatmasta wrote: post #46

Earlier quoted context omitted.

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.

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.

Re: Rust programs versus Go

#120

Post by acaloiar »

Before getting heated about the meaning of these results, remember that benchmarks are good for one thing: measuring performance.

Performance is important, but there is laundry list of other factors that programming languages optimize for. Because factors such as development pleasure, mean time to programmer error, and mean time to grok code are not easily quantified and compared, it's difficult to put two languages head-to-head on these often more important factors.

These results clearly show how Rust and Go compare on a small set of performance problems. And if you're trying to solve any of these problems using either of these languages, and performance is what you're optimizing for — Rust is a clear winner. I wouldn't try to extrapolate these results to mean anything more than that.

Post reply on HN