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

131–140 of 209 posts

Re: Rust programs versus Go

#131

Post by pcwalton »

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…

Did you try to spawn lots of threads? OS threads scale better than you'd think.

Re: Rust programs versus Go

#132

Post by chatmasta »

skywhopper wrote: post #105
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 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 rege…

Agreed... which is why I posted it here and it got 80+ comments. So there is a discussion now!

Re: Rust programs versus Go

#133

Post by kjeetgill »

simias wrote: post #123
PSeitz wrote: post #88

Earlier quoted context omitted.

Garbage collector is actually something you'd want, if it caused no performance hit.

Meh. I might have a huge Stockholm syndrome with manual resource management since I've basically started coding with C and used GC-free languages for most of my life since them but I never really understood why people liked GCs so much outside of scripting languages where convenience trumps correctness and you just litter your resources around instead of tracking them properly. Are people using GC languages really of…

From a Java programmer's perspective: I agree that a majority of your could would function just as well with RAII-style deallocations. That said, it's not too rare to throw objects around in queues or hashmaps and the garbage collector can save you from sloppy code turning into memory leaks.

Also consider, GC can "solve" a number of other issues. malloc() and free() aren't always cheap to do in the critical path especially when you have heap fragmentation. There are solutions without GCs, but compacting generational GCs combat both of these things without requiring you to even be aware of them. I'm not claiming they're always the best solutions but hopefully I've explained their motivations.

Re: Rust programs versus Go

#134

Post by vertex-four »

vanderZwan wrote: post #128
notheguyouthink wrote: post #115

Earlier quoted context omitted.

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.

Hmm, sounds like the kind of thing that is hard to get right then. Maybe it's for the best that it isn't in the standard library until the design and implementation stabilises then. Sucks for early adopters though!

I doubt Rust will ever get green threads - it turns out that OS threads are good enough, and futures (async/await) is how IO will get dealt with at scale. Green threads don’t help compute-bound code, so with a solution in place for IO, they’re unnecessary.

Re: Rust programs versus Go

#135

Post by divan »

ghr452 wrote: post #71
codedokode wrote: post #32

Earlier quoted context omitted.

Also, in readability Go wins. Because you don't have to put single quotes and HTML tags after every variable.

I think syntax ends up being mostly superficial. The real readability gains come from being able to map().filter().sum() instead of needing 3 for-loops mutating outer variables.

Which part of a for loop is unreadable?

Re: Rust programs versus Go

#136

Post by hellofunk »

notheguyouthink wrote: post #98
hellofunk wrote: post #53

Earlier quoted context omitted.

> Rust handles memory (de)allocation at compile time You are saying that Rust is doing its runtime memory allocation at compile time? Are you sure you don’t mean compile time management of memory? Two very different different things.

Isn't one of those impossible? Ie, there's only one reasonable interpretation of that sentence? Not saying being explicit isn't important, just trying to understand you.

Yes, what poster commented is in fact impossible.

Re: Rust programs versus Go

#137

Post by burntsushi »

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 in. :-)

The PCRE version is definitely sub-optimal. I don't think it's using the JIT, for example.

Enabling SIMD optimizations in Rust's regex crate shaves off another 13% (for Rust program) and 9% (for Go program). The SIMD optimizations will be enabled by default in Rust 1.27 for CPUs that support them.

Re: Rust programs versus Go

#138

Post by sagichmal »

logicallee wrote: post #130
sagichmal wrote: post #35

Earlier quoted context omitted.

"Systems programming language" has multiple, equally-valid definitions. This no-true-Scotsman rules lawyering about language classification is the least interesting possible discussion about a programming language.

you're right it's not an interesting semantic distinction, but it's weird to have people going around saying "but it is not (and does not intend to be) a systems language" when it's an explicit design goal for Go and explicitly mentioned in line 1 of its specifications. OK, not a very interesting discussion.

It's not intended to be a [Rust-style] systems language [in which one might implement a resource-constrained operating system].

It's absolutely intended to be a [Google-style] systems language [in which one might implement a large distributed data system].

Re: Rust programs versus Go

#139

Post by 1125 »

timClicks wrote: post #12
1125 wrote: post #6

They're sorted by highest delta, which makes it look so significant in the first moment. Also, though one of golangs target was to get close to c-like performance, they never intended to be the "performance-killer" since the focus is also strong simplicity and productiveness. More info: https://golang.org/doc/faq#Why_does_Go_perform_badly_on_benc...

Another angle where Rust is doing well is in peak RAM usage. Its memory usage is generally (although certainly not universally!) much lower in these examples.

Yeah, no doubt! As already written somewhere above, the GC is not cheap.

Re: Rust programs versus Go

#140

Post by yoklov »

atilaneves wrote: post #93
jon-wood wrote: post #9

Earlier quoted context omitted.

It’s less Go doing something wrong and more just that they do different things. Go has a garbage collector which will naturally slow things down somewhat, while Rust handles memory (de)allocation at compile time.

I'm still puzzled by the continued belief that a tracing GC will "naturally slow things down somewhat". Why do you think that's the case?

You’re forcing the program to rediscover facts about itself at runtime. This is not free.

That doesn’t mean a GCed lang is always slower than a lang where memory is managed manually. It means that the theoretically optimal implementation using GC has to do more work than the theoretically optimal implementation that manages its own memory.

In the case where the theoretically optimal implementation needs a GC, the unmanaged language could always implement that anyway, but that’s vanishingly rare — typically a GC gets its speedup by using pools, which are also available to unmanaged code.

Post reply on HN