Go vs Rust : Productivity vs Performance

Recently, I have been spending some time learning both Go and Rust languages and really excited about these languages evolving differently to solve different problems.

 I think Rust will attract developers from C, C++, Fortran and will be used for developing high performance systems like gaming, browsers, telco servers, distributed computing systems as well as low level, cpu efficient embedded/micro computers.

Go seems to be for the Python, Ruby and Java developers and will be used for enterprise applications, mobile apps and application servers.

With my 10+ years of experience in C++ writing applications for telecom service providers where latency and throughput is very important,  I really like Rust which simplifies C++ , eliminates memory corruption, improves compile time significantly and being claimed as blazing fast.


Today I came across Computer Language Benchmark comparing Rust and Go from one of the blog I was reading. These are microbenchmark and gives rough idea about how these languages perform for specific algorithm implementation.


Program Source CodeCPU secsElapsed secsMemory KBCode B≈ CPU Load
 binary-trees 
Rust22.055.97228,196788  96% 87% 95% 93%
Go68.4118.42266,624814  94% 94% 92% 93%
 pidigits 
Rust1.731.735,3081297  1% 100% 0% 0%
Go3.763.523,668674  4% 48% 7% 51%
 spectral-norm 
Rust7.872.065,1121020  95% 96% 96% 96%
Go15.703.961,816536  99% 99% 99% 99%
 reverse-complement 
Rust0.740.49257,1602015  12% 82% 41% 18%
Go0.930.77250,5641243  10% 69% 11% 35%
 fasta 
Rust4.995.004,8121224  1% 0% 100% 0%
Go7.267.271,0281036  1% 1% 1% 100%
 regex-dna 
Rust35.2611.95228,296763  65% 66% 87% 78%
Go47.4016.27543,868789  86% 64% 64% 78%
 fannkuch-redux 
Rust50.0112.817,0721180  99% 100% 97% 95%
Go67.1616.861,032900  100% 100% 100% 100%
 mandelbrot 
Rust20.145.0956,8241290  98% 99% 100% 99%
Go25.446.3932,276894  100% 100% 100% 100%
 n-body 
Rust20.9920.994,8241371  1% 0% 0% 100%
Go22.9522.951,0361310  0% 0% 100% 1%
 k-nucleotide 
Rust26.069.76152,5362113  42% 83% 43% 99%
Go30.938.42251,0241399  98% 91% 90% 90%

To get the comparative data across all these algorithms,   I calculated average for combined these algorithms for both the languages.

Results:  Average Elapsed seconds and code written for each language:


Language CPU (Elapsed seconds) Code (B)
Rust 7.585 1306.1
Go 10.483 959.5


These microbenchmarks shows Rust is ~30+% faster than Go but has ~30+% more code.


Given the computers are getting faster and cheaper but software becoming more complex and maintenance is expensive, I would use Go for an enterprise application.

Which language would you choose and for what kinds of applications?  



15 comments:

Anonymous said...

Calculating an overall average for tests with wildly different running times doesn't make any sense. The tests aren’t run sequentially, each one is a different benchmark and percentage performance on each test needs to be weighted equally (unless you have some reason to think the tests that took longer are more indicative of overall program performance for some reason, and that this importance is proportional to how long it took).

Naively taking the average *percentage* faster that Rust ran for each test, and dividing by the number of tests:

(18.42 / 5.97 + 3.52 / 1.73 + 3.96 / 2.06 + 0.77 / 0.49 + 7.27 / 5.00 + 16.27 / 11.95 + 16.86 / 12.81 + 6.39 / 5.09 + 22.95 / 20.99 + 8.42 / 9.76) / 10

I get that it ran more like 60% faster than Go, not 30%.

And using the same technique with code size:

(788 / 814 + 1297 / 674 + 1020 / 536 + 2015 / 1243 + 1224 / 1036 + 763 / 789 + 1180 / 900 + 1290 / 894 + 1371 / 1310 + 2113 / 1399) / 10

Rust has about 40% more code than Go, not 30%.

That’s ignoring whether these benchmarks are actually representative of anything in the real world, whether characters of code is a good representation of how hard it was to write the program, or how fast the *average* program is. Even if your conclusions are totally accurate, the way you arrived at them is not.

Rohit Joshi said...

Thanks for your data. I had come to the same number but generalized as roughly more than 30% ( ~30+% )

John Geffen said...

I'd use Delphi to maximize productivity and performance. Delphi has fast compile times, fast visual development, a good standard library and strong cross platform support. Delphi really is a rapid development environment, more so than anything else I've used.

Anonymous said...

>> I calculated average for combined these algorithms <<

Do you think there's a reason that web page does not show the arithmetic mean?

That web page already does show that the median difference between program elapsed times was small.


>> These microbenchmarks shows Rust is ~30+% faster than Go but has ~30+% more code. <<

And please don't jump to conclusions!

Rohit Joshi said...

I understand these are microbenchmarks (provided link in the blog).

I am not concluding but rather stating the fact that " These microbenchmarks shows Rust is ~30+% faster than Go but has ~30+% more code."

Anonymous said...

The web page you link to states-as-facts measurements of particular Rust programs and particular Go programs.

"For each named benchmark, measurements of the fastest Rust program are shown for comparison against measurements of the fastest Go program."

When you write Rust is faster than Go, you are generalizing and jumping to conclusions.


Measurement is highly specific -- the time taken for this benchmark task, by this toy program, with this programming language implementation, with these options, on this computer, with these workloads.

Anonymous said...

"""When you write Rust is faster than Go, you are generalizing and jumping to conclusions."""

Which is exactly what we SHOULD do, if we want to have an opinion and not inanely repeat "everything is relative".

That's what science does: it generalizes and comes to conclusions.

Now, you may argue that he went about it the wrong way, but not that he shouldn't generalize at all.

pyros2097 said...

You should checkout https://github.com/manastech/crystal it might just be another language which compares against these two

Andres Manz said...

Very nice, thank you. Less code does not always imply more productivity. If typing is the most time consuming task for you as a developer, you're doing it wrong. Sometimes (not always, of course), less code also means less expressive code. To me it is important that a language allows me to express my intents by writing self-documenting code.

In contrast, performance _can_ be a very imortant factor, especially in games.

Anonymous said...

Dig a bit further, and you will observe that the compile line for Rust sets an optimization level of three, while no such optimization level is set for Go. Not necessarily a fair comparison.

Anonymous said...

I think the author is missing the point here. Rust is not about being fast or not productive. It is about being safe. If i have to write more code but I know this code will prevent me some headaches I'll go for it.

Anonymous said...

> Dig a bit further, and you will observe that the compile line for Rust sets an optimization level of three, while no such optimization level is set for Go. Not necessarily a fair comparison.

Nonsense. Go (at least, the implementation anyone actually uses) doesn't offer any optimizations levels other than the default, which is a major contributor to its quick-compile-time. It's a very deliberate tradeoff, not "unfair."

> I think the author is missing the point here. Rust is not about being fast or not productive. It is about being safe. If i have to write more code but I know this code will prevent me some headaches I'll go for it.

If you don't need Rust's performance there are plenty of other safe languages to choose from.

Paul said...

When comes productivity, Java is the best language IMHO.

Anonymous said...

Go's compiler does very little optimizations. Once the Go team after Go 1.6 or so decides to make the compiler do more optimizations Go will be much closer to Rust in performance than now. In the end people will only choose Rust over Go if resource constraints are tight, GC pauses would be a problem, interoperability with C is much easier and those things. Some people might dislike Go, because the language is a bit too simplistic. Rust is only for systems programming and embedded stuff. That is the only place where today a language without a GC would be used. That is a bit sad as I really would like to play around with Rust at work. But it will never be for application development.

itouchnewbie said...

For those benchmarks where Go outperforms Rust in terms of speed, is that because of poor implementation in the Rust code? How would you explain the slowness in Rust code?