
Why Go and Rust are not competitors - untothebreach
http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors
======
jasode
Go and Rust competes in the narrow space of, " _what 's The Next Interesting
Thing to learn?_"

In that narrow sense, it doesn't matter that the underlying semantics and
runtimes of Go and Rust are targeted for different use cases. They get lumped
together in the same conversation because people have a vague sense that
something... (newer programming language, newer database engine, newer CSS
templating, etc)... will make their project better. In that nebulous cloud of
possible future benefits, it's understandable for people to mention both in
the same conversation. However once people get past the unspecified idea of
"better" and actually analyze (i.e. write concrete programs) the real costs &
benefits, the differences of Go & Rust will reveal themselves. People will
realize that Go is inappropriate to write a 60 fps graphics rendering engine
and likewise, Rust is inappropriate to write quick scripts for Google-scale
cloud orchestrations.

One other reason that Go is mentioned along with Rust is that Google used the
adjective "systems" to describe it. " _Go is intended as a systems language_
". Unfortunately, a lot of folks didn't realize that Google was using an
idiosyncratic definition of "systems" to mean a programming language to help
the management of their datacenters. To others, "systems language" means
writing operating systems, device drivers, embedded chips, etc. There was a
nuance that got lost and it ended up muddying the discussion. The phrases, "
_Go is a systems language_ ", and " _Rust is a systems language_ " look the
same but they mean different things.

~~~
cwyers
No, they meant Go was intended as a systems language. Rob Pike:

[http://commandcenter.blogspot.com/2012/06/less-is-
exponentia...](http://commandcenter.blogspot.com/2012/06/less-is-
exponentially-more.html?m=1)

> I was asked a few weeks ago, "What was the biggest surprise you encountered
> rolling out Go?" I knew the answer instantly: Although we expected C++
> programmers to see Go as an alternative, instead most Go programmers come
> from languages like Python and Ruby. Very few come from C++.

> We—Ken, Robert and myself—were C++ programmers when we designed a new
> language to solve the problems that we thought needed to be solved for the
> kind of software we wrote. It seems almost paradoxical that other C++
> programmers don't seem to care.

Read the whole thing if you have time - Pike talks about how they were trying
to write a language that filled a role similar to C and C++. So they came up
with a compiled, statically typed language.

~~~
jasode
I've read that and I disagree with your interpretation.

Google was using C++ in the "systems management" of their datacenters. Rob
Pike is using a Google-idiosyncratic definition of "systems".

I do believe that Google did use C++ for many classic low-level scenarios
(e.g. writing custom Linux device drivers, failover code, etc) but they _were
also_ using C++ for "high-level" systems orchestrations and batch jobs. It's
the "high-level" uses of C++ that that Rob Pike successfully addressed with
Golang.

I'm saying a large percentage of programmers outside the Google bubble think
of "systems" as low-level stuff like realtime embedded, low-latency device
drivers, etc that require zero-cost abstractions. Rob Pike did not design Go's
semantics & runtime for those use cases.

~~~
0xFFC
C++ for Linux device driver? Am I missing something?

~~~
FreeFull
It is possible to write a Linux device driver in C++, although most will be
written in C (and I think all the ones that actually come with the kernel are
in C).

------
amalcon
It seems pretty straightforward to me. Rust fits into more or less the niche
of C and C++: a low-level systems programming language with minimal runtime
dependencies (no garbage collection, smallish standard library), which happen
to also be useful properties for realtime and other perfromance-critical
software.

Go, on the other hand, fits more into Java's niche: an opinionated mid-level
garbage collected language designed for application programming or mid-level
systems stuff (i.e. web servers), with concurrency baked into the language
design (though Go's concurrency design is much more to my liking than Java's).

~~~
Hytosys
I mostly agree with your analysis. As someone who is doing web development in
Rust, what should I fear of missing from a language like Go or Java? Is it
just an ecosystem thing? Java is a more popular option for web server
development over C++, but I don't know why.

~~~
phn
Is Rust really suitable for web development? I am genuinely asking.

For server development I think it might be a good choice, but for application
code itself it seems like more of a pain to program in than an advantage.

~~~
rockdoe
Probably mostly depends on the libraries and frameworks that will appear? The
SQL query->data->template pipe isn't very reliant on the language as long as
it can manipulate "data" reasonably well.

Nobody wants to code C++ for webservers because of the risk (PayPal not
included) but Rust doesn't have that issue.

~~~
Shorel
Actually, some people use C++, with an OKCupid framework.

[https://github.com/okws/okws](https://github.com/okws/okws)

------
coldtea
> _Rust and Go are both touted as memory safe. While this statement is
> absolutely true, both languages will not tolerate unsafe memory access, what
> is more important is that the world will not tolerate any new language which
> is not memory safe. It just so happens that Go and Rust are the first two
> languages to emerge after decades of evidence that in the real world,
> programmers as a whole, cannot safely manage memory manually._

This is extremely misleading.

Go and Rust are not at all "memory safe" in the same way.

And Go and Rust the "first two languages" in this regard? Hardly.

Rust maybe, because it uses a novel approach, but there's absolutely nothing
special in Go's "memory safety" approach compared to Java (and Scala,
Clojure), C#, D, Haskell, etc.

~~~
infogulch
You took it the wrong way. Dave didn't say that Go's GC was special, of course
garbage collectors have been around for decades. The key takeaway:

> what is more important is that _the world will not tolerate any new language
> which is not memory safe._

Because of that, both Go and Rust, as a new languages, are not memory unsafe.
Go's safety is boring, sure, but it's still a feature of the language.

So both languages are memory safe in that they are not memory unsafe, big
whoop. That's Dave's point. _All_ new languages have this, and even though
they're commonly compared with this metric, the metric itself is useless for
new languages.

~~~
gyre007
>Rust and Go are both touted as memory safe. While this statement is
absolutely true

Duh?

>So both languages are memory safe in that they are not memory unsafe

This is more accurate statement imo. Saying Go is memory safe [1] is like
saying a lamb is safe among a heard of hungry lions.

[1] [http://www.pl-enthusiast.net/2014/07/21/memory-safety/](http://www.pl-
enthusiast.net/2014/07/21/memory-safety/)

~~~
infogulch
From that article, safe Go prevents: buffer overflow, use after free, use of
uninitialized memory, illegal free, access to undefined memory. The only thing
it misses is null pointer dereference. (OOM errors are not possible to prevent
in turing-complete languages.)

I don't agree with your analogy. A lamb among lions is _clearly very unsafe_ ,
but Go isn't unsafe; you just agreed with me on this. Your analogy fits better
to C/C++. The lamb could theoretically survive, but it's very unlikely; just
as unlikely as a C/C++ program with no memory bugs.

~~~
gyre007
Yes I do generally agree with you. I went a bit overboard - somewhat HN pushes
me over the edge sometimes :-(

Lamb metaphore would not do Go the justice indeed. I do like Go, but also do
not like some opinion which oversimplify reality.

------
Cshelton
So I've written a few things in Rust, none in Go, but I've looked through Go's
syntax.

Everything that can be written in Go can be written in Rust. However, Go would
be much more simpler for things, ie. right now, a web server. On the other
end, some critical performance things or microprocessors, etc., written in
Rust cannot be written in Go.

They each have a purpose, and while there is some overlap, the purpose is very
different. Go is geared more towards developer simplicity. Inevitably, Go will
be a more popular language because of the simplicity. Similar to Ruby and
Python. I also see Rust becoming a much more mature language that will take
many C and c++ programmers over the next few years. It takes time, 1.0 was
only released 7 weeks ago.

In the end, I see both of these languages growing more and sticking around for
awhile. Especially with large corporate backings (Google, Mozilla) and growing
communities.

I think I will probably learn both eventually.

------
alexatkeplar
> Go competes for mindshare [with those who] have lost patience with the high
> deployment costs of JVM based languages

This is repeated so often, but I genuinely don't understand the underlying
point. At Snowplow we have to deploy Scala, Java, JRuby and Go, amongst other
things.

Scala/Java: build a fatjar containing all dependencies using sbt-assembly,
upload to Bintray and then deploy onto servers which have a recent JVM.

JRuby: build a fatjar containing all dependencies using warble, upload to
Bintray and then deploy onto servers which have a recent JVM.

Go: build a binary containing all dependencies with godep for each relevant
server architecture, upload to Bintray and then deploy onto servers.

Yes, Go doesn't need a JVM installed, but on the flipside I have to build a
version for each relevant server architecture. And then there's the software
where I have to export GOMAXPROCS=`nproc` in a wrapper script...

~~~
commentzorro
The JVM, CLR, Frameworks, Runtimes, app servers, configurations, etc. _ARE_
the problem. We're tired of all that crap all the time. Compile to an
executable and xcopy the executable to an arbitrary server. Ideally, nothing
to configure outside of the application itself.

Go fits that bill nicely, but it's an annoyingly austere language. With all
the languages in this last wave, I just don't know why nobody hit on a full
featured Go level language yet. No memory management, not deployment
dependencies, full of nice sugary high level abstractions, and cross platform
Windows/Linux. Something solid and ready for production use, not an alpha or
beta.

~~~
alexatkeplar
> Compile [assemble] an executable and xcopy the executable to an arbitrary
> server [with a JVM]. Ideally, nothing to configure outside of the
> application itself.

That is exactly what we do with Java, Scala, JRuby. Installing a JVM is 5
lines of bash; 1 line of Dockerfile. I don't understand the point you're
making.

~~~
kasey_junk
Let me start by saying I think the argument for binaries vs fat jars is
overblown.

That said there is more complexity with the jvm. Do you have the _right_ jvm
installed? Where was it installed? Are there multiple versions of the jvm
installed? Do you care? Can you mess with it? Have you accepted the license
for the jvm? Should I use docker to manage all this complexity? Is the docker
agent working? etc.

In environments where you are deploying to a single architecture that is more
complex than "copy binary". In environments with LOTS of servers the
(admittedly limited) complexity difference can add up.

~~~
pjmlp
IT says everyone uses version X.

~~~
kasey_junk
This group IT, do they set up the servers? Do they make sure policy is
enforced? Do they deploy your software? If so, they are doing the work and we
should be asking them & not you whether they prefer JVM based solutions or
single binary ones.

~~~
pjmlp
Most of the companies I worked for, only IT has a say what devs have on their
machines and servers. You need tickets for everything.

------
pjmlp
Go is only a competitor for Java 1.0 like languages.

It is not a competitor to Rust, because it lives in enterprise mindset of 90's
language design.

It is not a competitor to the JVM languages, because all of them are more
feature rich and any knowledgeable JVM developer is aware there are plenty of
options to deploy, including static binaries.

~~~
kasey_junk
I have a lot of experience in the JVM and understand how to deploy, build,
etc. JVM based solutions including those built on "next generation" JVM
languages like Scala.

Go absolutely is a competitor to that environment because writing web services
across large teams is something Go has a compelling story around. This has
been the domain of the JVM for a long time and many people have bad
experiences with it (many people have good experiences as well I'd add).

~~~
aikah
> the JVM for a long time and many people have bad experiences with it

And the only reason for this is that people don't have to maintain 15 yo Go
code bases yet. But Go is verbose and will be a hell to maintain just like any
other language that becomes 'enterprisey', just like big nodejs code bases,
big rails code bases or big JEE code bases give people 'bad experiences'.

~~~
kasey_junk
I dont disagree at all. The one thing I would say _might_ mitigate this, is
that the golang community and leaders are very much rooted in the Unix
philosophy of doing one thing well. They push back very hard on things that
enable code bases to get big.

Its possible that golang will simply not be viable in use cases that require
big code bases, and therefore won't deal with those problems. Its also
possible that over time the focus on keeping things small will drift, and
golang will just be Java.

------
copsarebastards
Why are we still talking about this?

Every language that's vaguely close to a multi-purpose language is a
competitor with every other language. There are people who write websites in
X86 assembler and people who write embedded systems in Python.

Rust and Go are competitors. Yes, they were intended for different things, but
who cares? Any reasonable metric of language success is going to show one
language pulling numbers from the other. Pick your metric: users? There are
plenty of people who _aren 't_ using Rust because they're using Go, and vice-
versa. Successful projects? There are plenty of projects which _aren 't_ being
written in Go because they're being written in Rust, and vice-versa.
Reliability and safety? Maybe Go would have a reasonable type system if Rust
hadn't snapped up so many of the good thinkers in that field.

Arguing about whether languages are competing based on what they were intended
for is a pointless argument: there's no metric for success, no way to validate
who's right or wrong. Are we really going to spend time arguing over what
Google devs meant when they used the word "systems"? Seriously?

------
mands
I certainly see the need for Rust, a better, stricter and more modern C
designed for low-level tasks where both performance and correctness matter,
e.g. layout engines, game engines, OS kernels.

On the other hand Go seems more suited to system/server tools where good-
enough perfmance and quick startup matters more. I've noticed that people have
been converting Python and Ruby code-bases to Go, and its use in system tools
such as Docker, CoreOS, and Kuberentes. We're working in this area and have
considered jumping on the bandwagon and rewriting our Python prototype in Go
for the same reasons - performance, minimal runtime, strong ecosystem, some
'typing'. (Python made/makes sense atm as we're still very exploratory so
doesn't get in our way).

However upon investigation I was a bit disappointed with Go, although it has
an incredible ecosystem and active community. Perhaps its simplicity is also
an advantage although I found it counter-intuitive at times. However I can see
why it found use in a way that 'better' (IMHO) tools such as OCaml were unable
to.

We're still undecided as to what to use when/if rewriting our code. Funnily
enough I'm wondering if maybe C#/F# would work, now .NET has been open-sourced
and has a native compiler. A good language/runtime, stronger type-system, lots
of libraries, and potentially good performance with quick startup. I guess it
would be quite amusing if MS's tooling ended up as the best way to write Linux
system/server tools within those particular constraints.

------
BuckRogers
Cheney sounds on the money to me. Even with this ending- "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."

I agree. If you're a large company that has a lot of product which is backend
webservices and you have huge amounts of Ruby, Python (dunno who has large
amounts of Node, but that has to be sad)- then Go needs to be looked at pretty
hard. While some of Go's deployment advantages are nullified a bit thanks to
things like Docker and UbuntuCore, it's probably going to win on
maintainability with large codebases over time with new programmers coming in
the door over time. I wouldn't put up much argument against that. If running a
business and the choice was a 500KLOC codebase in Python, Go or Java.. I'd
prefer that is in Go. And no one starts out with 500KLOC, so the decision for
a new business would need to be taken seriously from the start.

It's cliche but if your problems match Google's, then Go is a great solution.
I think Go will be and already is wildly successful in this domain. The killer
feature that ensures this is the simplicity. I think anyone coming from any
language could pickup one of the "simple is better" languages like Go. That's
going to ensure the prophecy continues IMO. Doesn't mean I'm onboard as 1 guy.
I wouldn't have a problem with doing it for a job though. It'd be on my short
list of acceptable technologies I'd work with.

Doxsey in his response though with his Go for everything stance, is a bit
overzealous for me. I'd agree if it seemed right, but it doesn't seem right. I
don't see it. Fortunately for Go, he doesn't have to be right. I think what I
described as being Go's sweet spot in the industry will be more than enough.
That religiosity reads as someone who's overly excited and maybe trying to
keep Go in the news.

------
jaegerpicker
Yeah I think of go as an upgraded scripting language in a lot of ways. In a
lot of ways I think go or scala are going to become the standard "oh crap we
need to scale and preform better" web application languages. I think in most
cases if I'm building a green field web application on the server side I'd be
hard pressed to not choose go or scala at the beginning. Nearly as quick a
development cycle and a MUCH better scaling story.

Rust is too my a language aimed squarely at what I mentally model at tight
loop applications, web browser engines, game engines, real time network
servers etc... Go has amazing performance compared to python or ruby or even
node.js but the GC is still too unpredictable to work well enough for those
type of apps IMO.

------
ExpiredLink
Two fringe languages are not competitors. Who would have thought it.

~~~
coldtea
First, being fringe doesn't make you non-competitor automatically. Fringe
language can and often DO compete for the same niche.

Second, with support from most major shops, and being deployed even in
companies such as Apple, Mozilla, Facebook and more, Go is hardly "fringe" at
this moment.

~~~
rockdoe
What's the source for Apple, Mozilla (ok Facebook I'm less surprised)
deploying Go?

~~~
mseepgood
[http://www.golangprojects.com/golang-go-job-in-Senior-CDN-
De...](http://www.golangprojects.com/golang-go-job-in-Senior-CDN-DevOps-
Software-Engineer-Santa-Clara-Valley-Apple.html)

[http://daringfireball.net/linked/2015/05/06/applebot](http://daringfireball.net/linked/2015/05/06/applebot)

[https://blog.mozilla.org/services/2013/04/30/introducing-
hek...](https://blog.mozilla.org/services/2013/04/30/introducing-heka/)

