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?
1 comment:
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.
Post a Comment