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 Code | CPU secs | Elapsed secs | Memory KB | Code B | ≈ CPU Load |
|---|---|---|---|---|---|
| binary-trees | |||||
| Rust | 22.05 | 5.97 | 228,196 | 788 | 96% 87% 95% 93% |
| Go | 68.41 | 18.42 | 266,624 | 814 | 94% 94% 92% 93% |
| pidigits | |||||
| Rust | 1.73 | 1.73 | 5,308 | 1297 | 1% 100% 0% 0% |
| Go | 3.76 | 3.52 | 3,668 | 674 | 4% 48% 7% 51% |
| spectral-norm | |||||
| Rust | 7.87 | 2.06 | 5,112 | 1020 | 95% 96% 96% 96% |
| Go | 15.70 | 3.96 | 1,816 | 536 | 99% 99% 99% 99% |
| reverse-complement | |||||
| Rust | 0.74 | 0.49 | 257,160 | 2015 | 12% 82% 41% 18% |
| Go | 0.93 | 0.77 | 250,564 | 1243 | 10% 69% 11% 35% |
| fasta | |||||
| Rust | 4.99 | 5.00 | 4,812 | 1224 | 1% 0% 100% 0% |
| Go | 7.26 | 7.27 | 1,028 | 1036 | 1% 1% 1% 100% |
| regex-dna | |||||
| Rust | 35.26 | 11.95 | 228,296 | 763 | 65% 66% 87% 78% |
| Go | 47.40 | 16.27 | 543,868 | 789 | 86% 64% 64% 78% |
| fannkuch-redux | |||||
| Rust | 50.01 | 12.81 | 7,072 | 1180 | 99% 100% 97% 95% |
| Go | 67.16 | 16.86 | 1,032 | 900 | 100% 100% 100% 100% |
| mandelbrot | |||||
| Rust | 20.14 | 5.09 | 56,824 | 1290 | 98% 99% 100% 99% |
| Go | 25.44 | 6.39 | 32,276 | 894 | 100% 100% 100% 100% |
| n-body | |||||
| Rust | 20.99 | 20.99 | 4,824 | 1371 | 1% 0% 0% 100% |
| Go | 22.95 | 22.95 | 1,036 | 1310 | 0% 0% 100% 1% |
| k-nucleotide | |||||
| Rust | 26.06 | 9.76 | 152,536 | 2113 | 42% 83% 43% 99% |
| Go | 30.93 | 8.42 | 251,024 | 1399 | 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?
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).
ReplyDeleteNaively 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.
Thanks for your data. I had come to the same number but generalized as roughly more than 30% ( ~30+% )
ReplyDeleteI'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.
ReplyDelete>> I calculated average for combined these algorithms <<
ReplyDeleteDo 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!
I understand these are microbenchmarks (provided link in the blog).
ReplyDeleteI am not concluding but rather stating the fact that " These microbenchmarks shows Rust is ~30+% faster than Go but has ~30+% more code."
The web page you link to states-as-facts measurements of particular Rust programs and particular Go programs.
ReplyDelete"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.
"""When you write Rust is faster than Go, you are generalizing and jumping to conclusions."""
ReplyDeleteWhich 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.
You should checkout https://github.com/manastech/crystal it might just be another language which compares against these two
ReplyDeleteVery 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.
ReplyDeleteIn contrast, performance _can_ be a very imortant factor, especially in games.
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.
ReplyDeleteI 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.
ReplyDelete> 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.
ReplyDeleteNonsense. 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.
When comes productivity, Java is the best language IMHO.
ReplyDeleteGo'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.
ReplyDeleteFor 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?
ReplyDelete