Why Go and Rust Are Not Competitors (2015)

&quot;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.<p>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.&quot;

MORE of these headlines instead of &quot;Go is slower than Rust&quot; or &quot;Rust has more bells and whistles than Go&quot;.<p>I develop in both Go and Rust.<p>I use Go as main replacement for .NET&#x2F;Java web tier...no need for install specific Java or .NET run-time library.<p>I use Rust when there&#x27;s heavy disk reads and writes...and I know it&#x27;s a nightly job which should never segfault and never finish the execution since it crashed.<p>GO = useful for rapid prototyping and a good .NET&#x2F;JAVA middle-tier replacement.<p>RUST = you CARE about performance.<p>You can use both with FFI&#x2F;C - use Go as the carrier and use RUST where the functions should squeeze every bit of performance to do something...

&gt; 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.<p>To be fair, concurrency is baked the Rust type system itself. It&#x27;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&#x27;s based on (system threads, futures&#x2F;asyncio, maybe other things eventually?), while Go wants to provide a particular (very convenient) mechanism as part of the language.

I think the illusion of competition mostly comes from how Go was touted when it first came out. To quote the google announcement:<p>&quot;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.”<p>I was there when it happened, so regardless of the way go is being used and what it&#x27;s being touted for <i>now</i>, in 2009-2011 it was all about Google&#x27;s new systems programming language, set to replace both C and C++. And it was very clear that by &quot;systems programming&quot; Pike et. al meant any kind of job that was traditionally relegated to C&#x2F;C++: <a href="http:&#x2F;&#x2F;www.informit.com&#x2F;articles&#x2F;article.aspx?p=1623555" rel="nofollow">http:&#x2F;&#x2F;www.informit.com&#x2F;articles&#x2F;article.aspx?p=1623555</a><p>Rust came out only slightly later and was also touted as a system programming language. From the the rivalry sprang out.<p>It turns out that Go&#x27;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&#x2F;C++ had some foothold, but more often than not Go was replacing (or competing with) Ruby, Python or Node.<p>Rust, on the other hand, took over most of C++&#x27;s trade-offs and focuses (Zero-cost abstraction, expressive power and full control over memory management) while relatively neglecting I&#x2F;O, tooling, ergonomics and the stdlib in the beginning. This attracted a very different crowd that looked to solve very different problems.

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

They are both being used, where C and C++ were the only alternative<p>Some of the points to be made here is that C and C++ are being used for a very wide range of applications<p>So if you do compare Go and Rust, you will find distinct technical advantages and disadvantage<p>Rust&#x2F;Go are currently the C&#x2F;C++ alternative

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

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

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

An article about rust from 2015? Not worth reading.

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