
Go vs. Rust: Productivity vs. Performance (2014) - daviducolo
http://joshitech.blogspot.com/2014/11/go-vs-rust-productivity-vs-performance.html
======
kibwen
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!)

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

~~~
kibwen
It's a mistake to consider the benchmarks game a "can't even" problem, the
level of effort given to each language's implementations is all over the map.

This also isn't an utter dismissal of the concept of microbenchmarks, it's an
utter dismissal of the concept of microbenchmarks as used to compare language
implementations. Something like the TechEmpower web framework benchmarks is at
least marginally better because the tasks permit a wider variation of
implementations and at least pretend to do some kind of useful tasks, instead
of pretending to be an arbiter of implementation quality (which, as much as
the benchmarks game disclaims it, is still what people take it as).

~~~
igouy
>>the level of effort given to each language's implementations is all over the
map<<

Evidently the level of effort to contribute a working Rust spectral-norm
program is too high for anyone ;-)

>>pretending to be an arbiter of implementation quality (which, as much as the
benchmarks game disclaims it, is still what people take it as).<<

The benchmarks game is "just 10 tiny examples."

~~~
kibwen

      > Evidently the level of effort to contribute a working 
      > Rust spectral-norm program is too high for anyone ;-)
    

Or they just don't care and refuse to let the benchmarks game hold their free
time hostage. :P

~~~
igouy
That could be a respectable position; but not when "they" trash talk instead.
That just looks bad.

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

[0] [http://www.excelsiorjet.com/](http://www.excelsiorjet.com/)

[1] [http://robovm.com/](http://robovm.com/)

[2]
[http://www-01.ibm.com/support/knowledgecenter/api/content/SS...](http://www-01.ibm.com/support/knowledgecenter/api/content/SSYKE2_6.0.0/com.ibm.java.doc.60_26/vm626/GenericWrapper/commandlineoptions_jit.html?locale=en)

EDIT: Also forgot to add that we enterprise devs also have C#, F#, Swift,
C++14, C++/CX at our disposal

~~~
copx
[0] Price per developer (!) $3000, only supports Java 7. To compare, the price
of the Go compiler per developer: $0

I see one clear benefit right there.

~~~
dleskov
Low/zero cost is a benefit only if everything else is equal. Eclipse and
Netbeans are free, yet people pay for IntelliJ IDEA. We use an expensive
commercial GUI testing product because all the free and cheaper alternatives
sucked big time, and support was either poor or non-existent.

------
jpgvm
This article doesn't really match my experiences.

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
The article has a major flaw: it confuses productivity with LoC.

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

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

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

------
ExpiredLink
> _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, ...

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

~~~
kibwen
I'm not sure that Rust particularly cares about attracting Fortran
programmers. Fortran is a highly specialized language whose most powerful
asset is its enormous body of working code. That's not a market that needs
another competitor.

------
nickysielicki
they don't exist in the same space. Go is not a systems programming language
and Rust is not a scripting language.

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

------
snowysocial
Great article, and I have to say I completely agree with your point on using
go for enterprise level development.

------
flippinburgers
Go is a simpler language and as such it is a better language.

~~~
EugeneOZ
Then BASIC is most awesome language.

~~~
flippinburgers
Always use the simplest solution that solves the problem. I didn't realize
that BASIC has concurrency. /s

~~~
the_why_of_y
You wouldn't believe that there's a "Concurrent Basic" research project that's
putting a variant of the 𝛑-calculus into BASIC. Erik Meijer truly has some
strange ideas...

[http://research.microsoft.com/en-
us/projects/concurrentbasic...](http://research.microsoft.com/en-
us/projects/concurrentbasic/default.aspx)

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

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

~~~
pjmlp
Not take this as a post against Rust, I like the language and what is trying
to be achieved.

Just listing some of the issues, from my point of view, Rust currently faces.

It is not there if one is looking for uses cases where GC performance doesn't
matter e.g. Haskell, OCaml, .NET, JVM. All existing alternatives enjoy more
mature libraries, editors, supported OSes and so on.

It is not there if the goal is to replace C++ on the mobile platforms, as it
introduces hurdles and increases the development time versus using the vendor
tooling.

Specially in the iOS and Windows Phone, where C++ is a first class language. A
kind of Objective-Rust, Rust/CX are needed there, even if rustc is able to
cross compile.

On Mac OS X it is not there in regards to Swift tooling and available
libraries, additionally for many developers ARC and GDC might just be good
enough, even if Swift is less safe than Rust.

~~~
kibwen
What makes you suspect that Swift is less safe than Rust?

~~~
pjmlp
Multithreading safety with GDC is not ensured as in Rust, as for the rest, I
would say it is as safe as any Cedar/ML descendant.

