Rust programs versus Go

Yes the maintainer is. People have tried.

> Nobody is stopping Golang enthusiasts from posting the results with a slab allocator or some other third-party packages.

You've never witnessed the "game"'s maintainer interacting with people have you?

I find microbenchmarks mostly useless. There are just too many variables in play.

Also they tend to focus on the developer who optimizes code, not the journeyman developer in your company who actually writes code. C or Fortran looks fantastic on benchmarks, but if you forced all your developers to use C I doubt you'd see a similar outcome.

They seem to push developers in the direction of coming up with simple rules of thumb like "Go is 2x slower than C" or "Python is 10x slower than C" which is complete nonsense. It really matters what the code is doing.

In particular for server programs developers come to these conclusions without considering the multi-core environment they're working in. ie, redis is a really fast key-value store that will use 1 core on a 32 core machine.

And as it turns out all the tips and tricks to improving performance in these cases works in all the other languages too. So just what are we to conclude from them?

I suppose a nice simple math benchmark can demonstrate that LLVM or GCC is better at optimizing code than Go?

>> the regex one is a absolute festival of 'who brought a fast regex library to the gunfight'

Yes performant libraries are important.

Reddit can be decent IMO (e.g. reddit.com/r/golang)

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 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/ [1]: http://langserver.org/

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.

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?

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.

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.

Yes, benchmarks are important, which is why we should use proper ones. The Benchmarks Game is not one of those.

The problem is, that some of this benchmarks rules prevent the Go solution from using the same efficient code than its competitors, so the numbers are just not valid.

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

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?

> > the results are much more similar

Parent is talking about performance, not source code

If you use a LLVM compiler, _mm_cvtpd_ps just translate to LLVM IR and is not Intel specific anymore.

That instruction is SSE2. SSE2 instruction set is guaranteed to be supported on all x86-64 CPUs, be it Intel, AMD or VIA.

Similarly, the intrinsics are supported by all modern C and C++ compilers for decades already. Some compilers even generate SSE code by default for code like double x = 42.0 * y, in place of older x87 floating point instructions. x87 code is slower, and has multiple numerical stability issues.

> Not zero, because it does properly call all destructors.

I believe that there is an optimization that allows this to be completely avoided for types with only trivial or no destructors.

> The GO implementation has to use the platform allocator.

So does the Java implementation, and still it fares much (3x) better than Go.

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 things that are either impossible or not-known/difficult to add to a linear time implementation in an efficient way. The most popular features among these are backreferences and various types of lookaround.

However, it is completely unsubstantiated to say that Rust's regex engine is faster than PCRE. At best, you can say that they are competitive with each other, where one regex engine will do better than the other on various types of workloads. Many such cases are not at all related to the feature sets of regex engines, and probably more related to missed optimization opportunities. (Anyone who has implemented a regex engine knows that the size of the set of missed optimization opportunities is unbounded.)

There are of course some of those cases where it comes down to pathological differences. For example, since PCRE uses a backtracking engine even when it isn't necessary (they do have a so-called "DFA" matcher, but it must be invoked explicitly), that means it is susceptible to exponential behavior when Rust's regex engine isn't. But Rust's regex engine has pathological behavior too. The only difference is that Rust's pathological behavior takes the form of large constants, where as PCREs takes the form of exponential growth in the size of the text being searched.

> (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.

If you're talking about PCRE vs Rust's regex, then I see no reason to claim that one does more or less copying than the other. I suspect both do exactly as little as possible. Certainly, neither of them will copy the search text.

> GO just uses PCRE. (Which is weird, isn't RE2 a google project?)

No. Go has its own regexp engine: https://golang.org/pkg/regexp/

The benchmark showcased in the OP for Go uses PCRE, and that's presumably because Go's PCRE variant is faster than Go's native regex engine. See https://benchmarksgame-team.pages.debian.net/benchmarksgame/... and compare `Go #2` (PCRE) with `Go` (Go implemented regex engine).

Go's regex engine in the standard library is written in pure Go, and was written by the same person that wrote RE2. (I wrote Rust's regex engine, but it was heavily inspired by RE2.) Go's regex engine does not have all the same optimizations as RE2, and in particular, it suffers from some very high constant factors in many more cases than what RE2 and Rust's regex engine. While Go's regex engine doesn't exhibit pathological behavior in the form of exponential runtime in the size of the search text, it also can be handily beaten by PCRE in a number of non-pathological cases.

   binary-trees

   source    secs
   Go        28.80
   Lisp      8.49

You know what I would choose if I needed a garbage collected language.

Btw,the lisp version uses no fancy tree allocator, just plain standard lisp lists.

>> GO just uses PCRE

Currently, there are 4 Go regex-redux programs and 2 use PCRE.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

>> The GO implementation has to use the platform allocator

… because there doesn't seem to be a Go third-party or stdlib arena allocator.

"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.

There’s that kubernetes thing of course ;)

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

Rust is still figuring out its "async" story. Go figured it out, and went full steam ahead before the language was even made public - day 0, basically.

I'm not holding my breath for Rust dethroning non-perf-critical Go projects anytime soon.

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.

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

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

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?

What stuck out to me about the regex-redux benchmark is that PHP is faster than both of them! Is that because PHP is effectively a scripting language over C, especially for well-defined tasks like regex matching?

You aren't really going to experience Rusts complexity when your program is essentially just a single function, so it probably isn't really a fair comparison..

How about using a language where you can start at this moment?

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.

Right, you use aboriginal angle brackets instead.

source: good generics implementations

Haskell: 100%

All Other Languages: 0%

source: flawed generics implementations

Haskell: 0%

All Other Languages: 100%

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

Go doesn't really play in the "systems level" field all that much, tho. They even removed the "systems" bit from the Go home page.

Go doesn't compete with C, unless C was the wrong choice to begin with. Nobody is writing an OS in Go. It competes with Python and Node.

I've reduced my Python/Node code by roughly 92.5% after Go reached 1.0 and I couldn't be happier.

Depending on the GC and what the particular definition of "performance" is for your use case (Memory usage? Throughput? Latency? ...), they don't cause a hit. It depends.

For instance, if you never hit the GC memory limit in D, it's faster than manually managing memory since you never free it.

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 often thinking "uh, I don't know when I won't be needing this resource anymore, thankfully the GC will figure that out for me"? Because I certainly never do. Either the resource is scoped and I expect it to be destroyed at the end of a certain block RAII-style, or it's some longer-lived resource (connection handle, object in a videogame, Window object in a GUI) that I'm going to store in some container and destroy when I no longer need it. If I have multiple references and a complex dependency graph I might use a reference counted container which is effectively a very simplistic GC but it's the exception and not the rule and it's still completely transparent and easy to reason about.

I never, ever, feel like I'm missing a GC when I'm coding in Rust or C++. In C I miss destructors and RAII but that's it. I just don't understand why they're so popular, at best they save you a few lines of cleanup code in your destructors, at worse they make your code behave sub-optimally and non-deterministically because you don't know when your objects are going to be destroyed and your destructors are going to run. Then if you need to write critical code you have to carefully step around the GC to be sure that your perf will be deterministic.

I genuinely don't get GCs.

There's more to it than that. Having a garbage collector can be faster even, but would you take a faster program if it cost you memory footprint or predictability? It just depends on what you're doing.

if you look at how the benchmarks run i suspect they would disadvantage java. java is known for having slow startup times and also an optimising JIT that takes a while to kick in. go is definitely going to be faster for some command line application that takes 20s to run but if you have a long running process i think it will be much closer.

The fastest Go benchmark for regex-redux is using PCRE, which is not a native Go regex engine. It's written in C.

Awesome work, thanks !

What mem?