
Why Go and Rust Are Not Competitors (2015) - kgthegreat
https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors
======
kgthegreat
"Rust competes for mindshare with C++ and D for programmers who are prepared
to accept more complex syntax and semantics (and presumably higher readability
costs) in return for the maximum possible performance. For example, micro
controllers, AAA game engines, and web rendering engines.

Go competes for mindshare in the post 2006 Internet 2.0 generation of
companies who have outgrown languages like Ruby, Python, and Node.js (v8) and
have lost patience with the high deployment costs of JVM based languages."

~~~
Scarbutt
Curious, what are the "high deployment costs of JVM based languages"? Don't
must standard workloads simply deploy a jar?

~~~
jeremiep
Most likely some old myth regarding the JVM.

Its actually trivial to deploy and updates are just pushing one file; your
uberjar. This is so much better than anything node/ruby/python/php have to
offer.

I also feel much safer running code in a VM on the server than directly native
where a single invalid dereference brings down the whole thing in a rain of
fire.

~~~
zzzeek
The unbelievable irony I'm observing with the Java-based things I need to
deploy these days (Jenkins and Gerrit related) are that quite often they're
_making me build something_ , which then fails due to weird maven issues I
don't understand (since I haven't been a Java dev since the ant days).

The _entire point_ of java was that bytecode is portable, it's "write once,
run anywhere". Don't make me build your stupid .jar and figure out all your
dependency / build-time issues, just give it to me!

~~~
jeremiep
I don't think Jenkins is a good indication of modern Java :) If anything
Jenkins is a hairy ball of mud you should try to avoid :p

I write exclusively Clojure on the JVM now; its like having all the advantages
of the JVM and none of the inconvenients of Java!

------
wokawoka
MORE of these headlines instead of "Go is slower than Rust" or "Rust has more
bells and whistles than Go".

I develop in both Go and Rust.

I use Go as main replacement for .NET/Java web tier...no need for install
specific Java or .NET run-time library.

I use Rust when there's heavy disk reads and writes...and I know it's a
nightly job which should never segfault and never finish the execution since
it crashed.

GO = useful for rapid prototyping and a good .NET/JAVA middle-tier
replacement.

RUST = you CARE about performance.

You can use both with FFI/C - use Go as the carrier and use RUST where the
functions should squeeze every bit of performance to do something...

~~~
jeremiep
If you want rapid prototyping I don't think you can beat Clojure, not even
close.

Its really, really hard to beat the iteration cycle of a Lisp.

~~~
vram22
Python is not too shabby for this either. Command line + vim (substitute your
$EDITOR) and ipython and python and things can fly.

------
oconnor663
> Go is focused on concurrency as a first class concept. That is not to say
> you cannot find aspects of Go’s actor oriented concurrency in Rust, but it
> is left as an exercise to the programmer.

To be fair, concurrency is baked the Rust type system itself. It's certainly a
first class concept. I think the better way to describe it is that Rust wants
to make concurrency safe regardless of what mechanism it's based on (system
threads, futures/asyncio, maybe other things eventually?), while Go wants to
provide a particular (very convenient) mechanism as part of the language.

~~~
aplanas
I do not see that concurrency is a first class concept in Rust at all. The
only mechanism that is in the language are the Send and Sync traits, and is
even partially out of it.

Rust do not have language constructs for any concurrency/parallel model, and
this is a good thing. You can use fork-join, parallel iterators, mutex,
rwlocks, channels (mpsc, mpmc...) or any other model as a library.

The nice thing is that, as you say, is the type system the component that
guarantee a free from data race code in safe Rust.

~~~
oconnor663
Yes I think we're mainly using "first class" to mean different things, but we
can both agree that Rust and Go have both been designed very carefully around
concurrency :)

------
unscaled
I think the illusion of competition mostly comes from how Go was touted when
it first came out. To quote the google announcement:

"For that reason, Some smart Google engineers decided that it’s time to
address the limitations of C and C++ by designing a new programming language:
Go. [...] Go is based on the C programming family, one of the most widely used
programming language trees in the world [...] Go attempts to combine the
development speed of working in a dynamic language like Python with the
performance and safety of a compiled language like C or C++.We’re hoping Go
turns out to be a great language for systems programming with support for
multi-processing and object-oriented design, with some cool features like true
closures and reflection.”

I was there when it happened, so regardless of the way go is being used and
what it's being touted for _now_ , in 2009-2011 it was all about Google's new
systems programming language, set to replace both C and C++. And it was very
clear that by "systems programming" Pike et. al meant any kind of job that was
traditionally relegated to C/C++:
[http://www.informit.com/articles/article.aspx?p=1623555](http://www.informit.com/articles/article.aspx?p=1623555)

Rust came out only slightly later and was also touted as a system programming
language. From the the rivalry sprang out.

It turns out that Go's trade-offs and focuses (implementation simplicity,
relative familiarity, static compilation, solid tooling, solid stdlib and easy
concurrency) fit well for its eventual target demographics of web servers,
networking and command line tools. These are all places where C/C++ had some
foothold, but more often than not Go was replacing (or competing with) Ruby,
Python or Node.

Rust, on the other hand, took over most of C++'s trade-offs and focuses (Zero-
cost abstraction, expressive power and full control over memory management)
while relatively neglecting I/O, tooling, ergonomics and the stdlib in the
beginning. This attracted a very different crowd that looked to solve very
different problems.

~~~
k__
This.

People are move the goal post here.

Go has failed it's first goal. Rust hasn't.

But Go pivoted, and succeeded at their new goal.

------
3pt14159
I actually think that in the long run Rust and Go will have a similar
relationship between Ember and React. They'll have fundamentally different
approaches, but they'll steal the best ideas from each other (for example,
Glimmer is heavily influenced from React) and they'll both end up serving
their domains better and maybe overlapping a bit more here and there.

~~~
k__
lol, good comparison.

But what did React steal from Ember and what did Rust steal from Go?

~~~
3pt14159
There are lots of areas of speed optimizations that Ember introduced after
switching to Glimmer that React stole. Plus their CLI is very, very heavily
influenced by Ember's (which was influence by Rails).

~~~
k__
They have a CLI?

I only knew about CRA.

------
systems
They are both being used, where C and C++ were the only alternative

Some of the points to be made here is that C and C++ are being used for a very
wide range of applications

So if you do compare Go and Rust, you will find distinct technical advantages
and disadvantage

Rust/Go are currently the C/C++ alternative

~~~
k__
But it seems to me that Go is used especially by non C/C++ devs.

~~~
matt_wulfeck
Of course it is and it makes sense. Learning safe and correct C/C++ is a big
challenge. You _can_ do this, or write it in Go. It will be 80% as fast but
take you much less time. It will also be safe.

Once you’ve learned all of the ins-outs of C/C++ then you don’t have an
incentive to use Go to replace them. When you don’t need performance you can
use a scripting language like ruby or python. I see this happen often.

------
irfansharif
Not sure I quite understand the premise that there is a strict delineation
between programmers who are "prepared to accept more complex syntax and
semantics for <...>" and otherwise. I can think of a lot of cases where I'd
personally use either or (I've been looking into tikv contrasting it with
cockroachdb's storage layer for e.g.), a lot of cases where I've used Rust's
formalization of ownership/borrowing semantics to alleviate GC pressure in Go
code. I'm hard pressed to find projects "for" Go that Rust wouldn't be a
reasonable alternative to, and vice-versa.

------
fauigerzigerk
This sounds like an attempt to box Rust into a much smaller niche than is
justified.

------
rcthompson
Would the comparison have been more apt back when Rust used to have a garbage
collector?

~~~
oconnor663
And green threads! But maybe that was all before Rust was prominent enough to
count as a serious competitor?

------
xernobyl
An article about rust from 2015? Not worth reading.

~~~
abiox
why not?

------
jackmott
There will be some crossover since Go's AOT compilation and low latency pause
times will make some things that needed to be done in C++ or Rust viable in
Go.

~~~
themihai
>> make some things that needed to be done in C++ or Rust viable in Go.

like "micro controllers, AAA game engines, and web rendering engines"? I
highly doubt it! Swift 5+ might have a chance but Go has none(as it is now).

~~~
nine_k
Many controllers are not hard-realtime. Think e.g. of microwave ovens or smart
locks. Often you might be willing to trade a 10ms GC pause of Go for much
lower chances of memory corruption or crashing compared to C.

~~~
vvanders
Many controllers have almost zero memory headroom meaning your GC pauses get
an order of magnitude slower if not more as you have less than 2x your working
set.

Also, most of the applications never allocate because they can't even afford
the overhead of pooling/freelists that come with a stock malloc
implementation.

~~~
abiox
is a gc all that relevant if you're not dynamically allocating in either case?

~~~
vvanders
Garbage collection by its nature implies dynamic allocation.

You're using value types and raw pointers in those targets because even the
memory overhead of a heap/freelist/etc can be too much. With things like AVR
you're looking at 512B to 16kB of total memory(part of which includes the code
you write).

~~~
abiox
> Garbage collection by its nature implies dynamic allocation

i'm not sure i follow - you're saying that a gc existing implies that one
cannot preallocate and avoid dynamic allocation?

~~~
vvanders
> preallocate

This will still use dynamic allocation to do the preallocation. You'll have a
heap to track this which comes with its own overhead.

~~~
abiox
i guess i was using 'dynamic allocation' to mean allocation that occurs in the
midst of the main control flow, likely in response to some conditional
evaluation (vs upfront).

~~~
vvanders
Yeah, if you allocate in the main loop or preallocate you're still going to
pay the overhead of a heap to keep track of those allocation :).

