Taking an average of wildly varying microbenchmark scores doesn't seem particularly useful. Furthermore Rust has never had particularly optimal implementations for the benchmarks game (I can't speak as to the quality of the Go implementations). Furtherfurthermore this blog post is so old that the Rust results cannot be considered representative. Furtherfurtherfurthermore I would like it if we could just all collectively stop treating the benchmarks game as though any of its microbenchmarks measure anything other than "is this language capable of binding to libpcre" or "is this language capable of binding to libgmp". I swear, the benchmarks game is the SunSpider of programming language comparisons.
(Furtherfurtherfutherfurthermore, why are we still comparing Rust to Go? I thought we had gotten over this!)
>>Taking an average of wildly varying microbenchmark scores doesn't seem particularly useful.<<
Correct. Which is why, unlike Rohit Joshi, the benchmarks game simply shows a broad median; and when a summary measure is required to order the box plots, uses the geometric mean:
(Note the reminders -- "Please don't obsess over tiny differences in median values from such a small number of examples." -- "Please don't obsess about which programming language implementation is shown 10th and which is shown 11th. You can see that the order would be different if it was based on the median scores instead of the geometric mean scores.")
>>as though any of its microbenchmarks measure anything other than "is this language capable of binding to libpcre" or "is this language capable of binding to libgmp"<<
Incorrect. Everyone can see that there is only 1 regex task and only 1 arbitrary precision arithmetic task -- and they sensibly allow library use.
Although you are of course correct, I would caution against a complete dismissal of micro benchmarks.
Firstly because they are a sort of marketing: I've perused the shootout before and noticed an implementation get a higher score than I was expecting. This has sparked an interest in digging deeper into that implementation/language.
Secondly because of the "can't even" problem i.e. why should I invest time investigating a new language if it can't even do simple benchmarks well? I appreciate that this isn't a particularly analytical view but I expect that it's not uncommon.
> Go seems to be for the Python, Ruby and Java developers and will be used for enterprise applications, mobile apps and application servers.
No thanks, Go offers no benefit over the Java eco-system, neither in terms of deployment[0][1][2], not in terms of libraries and dependency management, nor in language expressiveness (Java 8, Scala, Clojure, Kotlin, Ceylon, Groovy)
I have found Rust to be considerably more expressive than Go.
Traits and proper generic types, iterators and pattern matching all contribute to this.
I tend to write less lines of Rust code to accomplish the same tasks.
As for runtime performance, in my experience they are pretty close right now for my use cases but I do expect Rust to grow faster than Go over time.
I think Rust is a fledgling this time. But I love the clearly orientation that they focus on. It is a safety system language, especially, the ownership/borrowing.
"Go seems to be for the Python, Ruby and Java developers and will be used for enterprise applications, mobile apps and application servers."
Out of interest, what would I gain by learning GO?
I already know Python pretty well. I have done Java in the past and don't see any problem jumping back into it. Both languages have tons of libraries and tooling available. Are mature, and I can't see much reason to opt for a new language.
> what would I gain by learning GO? I already know Python pretty well.
A significantly easier deploy story. Compile once on your target platform (i.e. Ubuntu), run on any of the same platform, without having to worry about installing (or how to install) all of your third party dependencies.
It's also more friendly to less skilled developers, with its type system and limited metaprogramming.
It also has a really compelling concurrent programming paradigm which doesn't involve libraries or pickle.
Of course, those same strengths are also weaknesses - the language is less expressive and flexible, and it requires extra steps to compile and distribute those compiled binaries.
> 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.
People choose platforms, stacks, languages, environments, not languages: Rails not Ruby, browser not JavaScript, Unix not C, host not Cobol, ...
Fortran programmers will never move to Rust. The level of systems knowledge required to use Fortran is almost nothing. It is already a pretty safe language due to the heavy restrictions on pointers and compiler warnings. The abstractions and restrictions in Rust will make it completely unpalatable to the scientific community.
Despite being always interested in seeing benchmarks comparing new languages I don't feel like basing my choices on such benchmarks. From my experience it's usually a matter of how comprehensive is the ecosystem surrounding the language. Anyway, great article.
Rust's not there yet and I wonder if it can compete. The thing is it is too specialized and low level (not that it is a bad thing for what it is intended for). The problem with all of the low-level things is that they are seriously undervalued.
I am glad that there is servo but we need something like an operating system (IoT might work for the start). I hope Samsung changes its plans with Tizen and eventually will develop something with Rust in mind.
I have heard a couple of comments about Rust not being "there" yet. Why is it not "there" for you? Where, precisely, is "there"? I certainly hope you are not basing this opinion on a blog post from 2014 with terrible methodology (even the maintainer of the benchmarks came down to comment on how egregiously he was misusing the numbers).
I wouldn't be worried about Rust competing, just because HN revolves around web tech doesn't mean the rest of the world undervalues systems programming. :)
Every big data platform I know of is or already has implemented manual memory management (they all run on the JVM). I can see Rust doing well in this world. It's hard to say things like Spark are undervalued. (Two data points: ~$50M investment in Databricks, the company commercialising Spark. IBM just committed ~3.5K developers to working on Spark projects.)
[+] [-] kibwen|10 years ago|reply
(Furtherfurtherfutherfurthermore, why are we still comparing Rust to Go? I thought we had gotten over this!)
[+] [-] igouy|10 years ago|reply
Correct. Which is why, unlike Rohit Joshi, the benchmarks game simply shows a broad median; and when a summary measure is required to order the box plots, uses the geometric mean:
http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
(Note the reminders -- "Please don't obsess over tiny differences in median values from such a small number of examples." -- "Please don't obsess about which programming language implementation is shown 10th and which is shown 11th. You can see that the order would be different if it was based on the median scores instead of the geometric mean scores.")
>>as though any of its microbenchmarks measure anything other than "is this language capable of binding to libpcre" or "is this language capable of binding to libgmp"<<
Incorrect. Everyone can see that there is only 1 regex task and only 1 arbitrary precision arithmetic task -- and they sensibly allow library use.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] lucozade|10 years ago|reply
Firstly because they are a sort of marketing: I've perused the shootout before and noticed an implementation get a higher score than I was expecting. This has sparked an interest in digging deeper into that implementation/language.
Secondly because of the "can't even" problem i.e. why should I invest time investigating a new language if it can't even do simple benchmarks well? I appreciate that this isn't a particularly analytical view but I expect that it's not uncommon.
[+] [-] pjmlp|10 years ago|reply
No thanks, Go offers no benefit over the Java eco-system, neither in terms of deployment[0][1][2], not in terms of libraries and dependency management, nor in language expressiveness (Java 8, Scala, Clojure, Kotlin, Ceylon, Groovy)
[0] http://www.excelsiorjet.com/
[1] http://robovm.com/
[2] http://www-01.ibm.com/support/knowledgecenter/api/content/SS...
EDIT: Also forgot to add that we enterprise devs also have C#, F#, Swift, C++14, C++/CX at our disposal
[+] [-] copx|10 years ago|reply
I see one clear benefit right there.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] jpgvm|10 years ago|reply
I have found Rust to be considerably more expressive than Go. Traits and proper generic types, iterators and pattern matching all contribute to this. I tend to write less lines of Rust code to accomplish the same tasks.
As for runtime performance, in my experience they are pretty close right now for my use cases but I do expect Rust to grow faster than Go over time.
[+] [-] kele|10 years ago|reply
[+] [-] anhtran|10 years ago|reply
[+] [-] collyw|10 years ago|reply
Out of interest, what would I gain by learning GO? I already know Python pretty well. I have done Java in the past and don't see any problem jumping back into it. Both languages have tons of libraries and tooling available. Are mature, and I can't see much reason to opt for a new language.
[+] [-] falcolas|10 years ago|reply
A significantly easier deploy story. Compile once on your target platform (i.e. Ubuntu), run on any of the same platform, without having to worry about installing (or how to install) all of your third party dependencies.
It's also more friendly to less skilled developers, with its type system and limited metaprogramming.
It also has a really compelling concurrent programming paradigm which doesn't involve libraries or pickle.
Of course, those same strengths are also weaknesses - the language is less expressive and flexible, and it requires extra steps to compile and distribute those compiled binaries.
[+] [-] ExpiredLink|10 years ago|reply
People choose platforms, stacks, languages, environments, not languages: Rails not Ruby, browser not JavaScript, Unix not C, host not Cobol, ...
[+] [-] unfamiliar|10 years ago|reply
[+] [-] nickysielicki|10 years ago|reply
[+] [-] alediaferia|10 years ago|reply
[+] [-] snowysocial|10 years ago|reply
[+] [-] flippinburgers|10 years ago|reply
[+] [-] EugeneOZ|10 years ago|reply
[+] [-] honest_joe|10 years ago|reply
I am glad that there is servo but we need something like an operating system (IoT might work for the start). I hope Samsung changes its plans with Tizen and eventually will develop something with Rust in mind.
[+] [-] Jweb_Guru|10 years ago|reply
[+] [-] kibwen|10 years ago|reply
[+] [-] noelwelsh|10 years ago|reply