
Go vs. Rust? Choose Go - mpweiher
http://matthias-endler.de/2017/go-vs-rust/
======
Animats
Much as I like Rust, I have to agree. When you have to get it done, use Go.
When you want to explore advanced experimental programming constructs, use
Rust. The Go guys knew when to stop. Arguably they stopped too early, before
generics or parameterized types, and "interface[]" is used too much. But that
doesn't seem to be a big overhead item.

Rust has the complexity of C++ plus additional complexity from the functional
community. Plus lots of fancy template cruft.

The trouble with language extensibility is that people use it without an
overall plan. The end result is a Winchester Mystery House language.[1] LISP
went down this rathole, and Scheme had to be developed to get out of it. C++
went that way when nobody stopped the Boost crowd before it was too late. Now
it's happening to Rust.

(Anyone involved in language design should see Václav Havel's "The
Memorandum". Or at least read it; I've seen it performed, but it's not
performed often.)

[1]
[http://www.winchestermysteryhouse.com/](http://www.winchestermysteryhouse.com/)

~~~
adamnemecek
> Rust has the complexity of C++ plus additional complexity from the
> functional community.

Not even close. C++ has IIRC whole books just on exception handling. And it's
crazy how many styles of writing C++ there really are. Exceptions or not,
standard library or not, templates or not, boost or not, etc, etc. C++
templates are a language of their own. A lot of times, if your code made a
particular choice, you are stuck with a set of libraries that made the same
choice, or you'll be writing an insane amount of boiler place to duck tape it
together. This code tends to be some of the most sucky code in existence.

Rust on the other hand feels very cohesive and there seems to be like one
style of really writing it.

What parts of Rust do you find experimental? The only thing that's new (in a
popular language) is the borrow checker but we can all agree that despite it's
novelty, it's a huge step forward.

Another thing about Rust is the community. Just about every Rust package I've
come across was very well written. Some even teach me a thing or two. E.g. I
haven't seen trees implemented the way they are in this package previously
[https://github.com/PistonDevelopers/history_tree](https://github.com/PistonDevelopers/history_tree).

Go packages are more all over the place. Also the community seems to
concentrate mostly on web stuff. The recent Vulkan tutorial by the Khronos
group (i.e. the people behind the standard) used Vulkano.rs which blew my
gourd. [https://www.khronos.org/blog/beginners-guide-to-
vulkan](https://www.khronos.org/blog/beginners-guide-to-vulkan)

> Now it's happening to Rust.

Please elaborate.

> Václav Havel's "The Memorandum"

It's crazy that you are aware of this, I always thought that his work had only
a local appeal.

I've written a modicum of Go and the boiler plate was driving me crazy.

~~~
Animats
Most things about Rust are well thought out and well designed. It's the total
weight that gets you. Like LISP, back when too many smart people from MIT were
adding to it without an overarching vision. It's hard to keep it all in your
head. The add-ons aren't libraries with specific functions; they're new
control structures. This gives me the feeling I had dealing with the MIT Loop
Macro.[1] Proliferation of control structures is not a good thing.

 _> Václav Havel's "The Memorandum"_

 _It 's crazy that you are aware of this, I always thought that his work had
only a local appeal._

Saw it at Fort Mason in SF in the 1990s.

 _I 've written a modicum of Go and the boiler plate was driving me crazy._

That's how I felt about Rust. See some code I wrote at [2], at "Return type
and its error handling". Now that's boilerplate. The last time I mentioned
this, it was brushed off with "Oh, you'll be able to do that with the '?'
operator when it's implemented." Feel free to submit a pull request for the
rewrite.

[1] [https://www.cs.cmu.edu/afs/cs/project/ai-
repository/ai/lang/...](https://www.cs.cmu.edu/afs/cs/project/ai-
repository/ai/lang/lisp/code/iter/loop/mit/0.html)

[2] [https://github.com/John-Nagle/rust-
rssclient/blob/master/src...](https://github.com/John-Nagle/rust-
rssclient/blob/master/src/rssread.rs)

~~~
adamnemecek
I get your lisp comparison but the fundamental difference is that in rust even
the craziest stuff is bound to be safe. I wouldnt be comfortable doing this
sort of stuff in other languages, but I'm OK doing it in rust.

Re error handling, Option's map method doesn't do the trick? Sorry on my phone
and reading code is hard.

------
webkike
It may be true that Go is easier to use than Rust but over time I have learned
to essentially love Rust and hate Go. Rust isn't perfect by any means, but
when I program in Go a lot of times I wish I could avoid costly abstractions
that don't have any real reason for being required, and thus I usually avoid
Go for any task I wouldn't just use Python for (sans the REPL). Go doesn't let
me describe data the way I want it to let me. Concurrency is not even
incredibly profitable using language idioms. I like the syntax, but frankly Go
is in an entirely different league than Rust is. And that is to say, when I
want to write a program Go sometimes is just not an option. Rust is always
available, even if you have to do a little bit of learning.

~~~
aaron-lebo
What about Nim? I've found that a lot more productive than Rust even without
libs.

~~~
mlevental
how's the compile time with nim? go's compile time makes it almost as good as
having a repl. i tried crystal a while ago and it has atrocious compile times.

~~~
dom96
The compile times are on par with Go. The Nim compiler (written in Nim and
containing ~100k LOC) compiles in under 10 seconds on my MacBook Pro, and this
is from a cold cache. It's even faster when making changes as the C source
files generated by Nim are cached.

~~~
mlevental
tangential question: are there still compiler bugs?

~~~
dom96
Of course, all software has bugs :)

~~~
wyager
This is not true, and shouldn't be used as a lazy excuse to write bad
software. There is absolutely software that is entirely free of bugs; it just
takes formal methods to get there for software of any reasonable complexity.

~~~
webkike
You can never however guarantee that a program will run free of errors.
Hardware is faulty and not always in ways that are human caused:
en.m.wikipedia.org/wiki/ECC_memory

------
bad_user
> _Both languages seem to be competing for the same user base and they both
> seem to be "systems programming" languages, so there must be a winner,
> right?_

No, Go isn't a systems programming language because it has a GC.

This matters in constrained environments, like when doing embedded
development, or for real time systems.

Sorry, but Go isn't in the same category as Rust or C/C++.

Go is in the category of Java and C#. And IMO its only advantage is that it
can produce lighter binaries.

And while Java and .NET are evolved towards building lighter binaries, you
can't evolve a GC-ed language towards one without a GC.

~~~
Jdam
> Sorry, but Go isn't in the same category as Rust or C/C++.

From the article:

> 99% of the time, Go is "good enough" and that 1% where it isn't, you'll
> know. And then take a look at Rust, because the two languages complement
> each other pretty well.

~~~
SideburnsOfDoom
Yes, that means that 99% of the time you don't need a systems programming
language. It's probably also true, depending on the specific case.

------
bfrog
I chose rust after endless annoyances in a 100kloc go program due to piss poor
type safety and nil pointer checks, lack of meaningful containers, and working
around GC when working with C libs. I didn't think I needed any of those
things until it was too late. Any project of meaningful size will eventually
need everything go avoids.

~~~
egeozcan
You rewrote a 100K LOC project because you felt the language is lacking! It
really must have been a huge battle with the management (or whatever
stakeholder there is), I suppose? If you did make your case against others,
could you please share how you went about that?

~~~
bfrog
No, I didn't rewrite it. But the next project I worked on I no longer
considered Go an option

~~~
egeozcan
Oh now I see how I've misread that, sorry!

------
LambdaComplex
"Rust and Go are both systems programming languages, so we have to compare
them! Go wins because it's easier. By the way, Go isn't a systems programming
language and would suck for systems programming."

That's basically what I got from this article.

~~~
qyv
The point of the article is that Go and Rust don't actually serve the same
purpose. So asking "Go or Rust" 99% of the time means choose Go. For the other
1% of the time you (should) know that you actually need Rust, not Go.

~~~
lordCarbonFiber
The problem with performance is that "you don't need it" right up until the
moment you do. It's the same argument startups use for writing their apps in
python. You get your "massive dev output" right up until you realize your web
app isn't going to scale and you've got to do a full rewrite and runtime
errors have burnt out most of your dev team.

There's a reason why the lion's share of code written today is Java or C++ and
Rust compares much more favorably on the more "enterprisey" merits (stability,
expandablility, performance) than the startup merits (how fast can we ship).

------
didibus
Why not Java, Kotlin, Scala, Clojure, C#, F#, OCaml, CL, Scheme, Haskell, or
any other efficient GC language?

Its funny to compare Rust, whose sole purpose was to enable garbage collector
free semantics, designed to reimplement an efficient and small memory web
browser to languages with a GC.

Go is great, because compared to most other GC languages, it has small self
contained binaries and comes with a great toolchain. Its AOT is better then C#
and Java, and bundles its runtime with every app. It's not great, because
people would really just want a more expressive language that had those same
qualities. That's why there's effort for Kotlin native and Scala native.

If anything, the fact that some people are thinking to pick Rust over Go is a
testament to Rust. Rust should have nothing of interest over Go, except for no
GC. But apparently, even with the added complexity of a borrow checker, it has
enough to entice people from GC languages.

------
dpc_pw
Productivity comparisons are tricky. As an analogy: Being more than 10 years
long Vim user, I am very productive with Vim. I have all my configs polished,
I know all the tricks, etc. I can work on shell scripts, C, C++, D, Rust,
Python, Go, anything... all in one editor, locally or through ssh, on any
platform, etc. But if you take a person that has spent a month using Vim, and
a person that has spent a month using some popular IDE, the IDE person is
going to be more productive. Also, I'm sure long-term Java IDE user is going
to be more productive than I am with Vim, when writing Java. Obviously.

Similarly with Go and Rust, as I'm following Rust development since like 0.3,
I am very productive with Rust, while I find Go noisy, verbose and constantly
dragging me down with its limitations. I don't have to be "architect
astronaut" to need generics or decent macros.

On top of that: how do you measure productivity? Many people seem to measure
it by "perceived productivity when writing new code". "I am writing this new
service in Go, and I was able to do 500 lines today. I feel very productive!"
Never mind that 30% of that lines are verbose error checks and other error-
prone boiler-plate, reviewing it might not be pleasant, there are multiple
errors that will have to be ironed out when production starts to exhibit them,
everything needs refactoring because performance is not good enough under
load, and that the next person might not have a such a wonderful time
modifying the original code, as the first person writing it, and so on. The
project might be in such a bad shape, then it will just get rewritten from
scratch, so the next developer will feel "productive" again, ironically. I am
NOT addressing Go and Rust particularly here - just overall. It is very hard
to measure long-term productivity, while it is easy to lure yourself into
believing the perceived short-term productivity matters a lot.

Having said all that, Go is easy to understand, so it is easy to find people
that are able to use it (huge business reason to prefer it!), has a nice
ecosystem, fast compilation, nice scalability with goroutines and many things
that are going for it.

I find Rust's "quality", trump Go's "productivity", but that's like ... my
personal opinion, man. :)

~~~
zzzcpan
I think people who come to Go from not so productive languages might feel
productive in Go. I mostly feel very unproductive with Go, like I'm wasting
too much time dealing with code, when I should be thinking about the problem
I'm solving. Although I almost completely stopped using Go at this point.

~~~
dpc_pw
If I was to use Go, I would just use D instead. It's a much better language
with similar strengths. Just didn't get as much "hype". Well, and had a couple
of other issues but oh well...

Having said that, since Rust 1.0 was released, I'm not planning to use any
other language unless paid for it. My favorite part of Rust is that it might
not be the best tool for a particular job, but is reasonably close for
anything I might throw at it: embedded, system tools, networking, web,
whatever. Since I'm a generalist, I enjoy having a reliable multi-tool.

------
yawaramin
Or choose OCaml: [http://engineering.issuu.com/2015/09/17/ocaml-
production.htm...](http://engineering.issuu.com/2015/09/17/ocaml-
production.html)

It's enterprise-ready. Seriously.

Hate the syntax? Wait a little bit and try out ReasonML (new syntax for
OCaml), e.g. the following OCaml

    
    
        channel
          |> Channel.push "new_msg" [%obj { body = "a" }] ~timeoutMs:10_000.0
          |> Push.receive "ok" (Js.log2 "Created message")
    

will become (pretty much) the following Reason

    
    
        channel
          |> Channel.push("new_msg", { "body": "a" }, timeoutMs::10_000.0)
          |> Push.receive("ok", Js.log2("Created message"));

~~~
mlevental
in what sense is ocaml production ready? does it have the tooling? ecosystem?
is there even another stl than jane street's library?

~~~
aidenn0
As a meta comment, there will always be detractors of any even slightly
esoteric language.

The author of pgloader[1] said the other day "When I told people I was going
to use Lisp, I was told it was stupid because there weren't any libraries;
when I packaged it for Debian, I was told that I had too many external
dependencies"

It was probably different groups, but there were complaints both about not
enough and too many libraries!

1: [http://pgloader.io/](http://pgloader.io/)

~~~
sanxiyn
FYI, here is list of pgloader (direct) dependencies (35 of them): abnf,
alexandria, asdf, asdf-finalizers, asdf-system-connections, bordeaux-threads,
cffi, command-line-arguments, csv, db3, drakma, esrap, fad, flexi-streams,
interpol, local-time, log, lparallel, markdown, md5, metabang-bind,
postmodern, ppcre, py-configparser, qmynd, quri, simple-date, split-sequence,
sqlite, trivial-backtrace, trivial-utf-8, unicode, usocket, utilities, uuid.

~~~
aidenn0
List of what they do, summary first, then detailed:

Portability libraries[1]6: bordeaux-threads, CFFI, command-line-arguments,
trivial-utf-8, trivial-backtrace, usocket

Parsing 6: abnf, esrap, markdown, py-configparser, simple-date, quri

Database interfacing 5: csv, db3, postmodern, qmynd, sqlite

Build-tool/dependency management 3: asdf, asdf-finalizers, asdf-system-
connections

utilities 3: alexandria, split-sequence, utilities

portable I/O & character encoding 3: unicode, fad, flexi-streams

sugaring 2: metabang-bind, interpol

Other 6: drakma(HTTP), log, lparallel, md5, ppcre(regex), uuid

abnf: parser generater for augmented BNF

alexandria: utility library

asdf-*: build-tool

bordeaux-threads: mutithreading primitives

cffi: foreign function (i.e. calling C)

command-line-arguments: exactly what it says on the tin

csv: comma separated variables (also supports similar things like tsv)

db3: dBASE III reader

drakma: http client

esrap: Parser generator

fad: Files And Directories (portable file-system)

flexi-streams: in-memory streams (file-like objects) and encoding

interpol: interpolated strings (e.g. variable substitution in strings). Also
includes regex literals.

local-time: timestamps &c.

log: logging

lparallel: high-level threading

markdown: markdown

md5: md5

metabang-bind: macro library for doing various fancy bindings (setting a
variable to a value for a particular lexical or dynamic scope) in a single
construct.

postmodern: Postgresql interface library

ppcre: perl compatible regex

py-configparser: parser for .ini like files (compatible with the python
"configparser" library)

qmynd: MySQL library

quri: fast URI parsing/emitting library ("quicker" than puri, the Portable URI
parsing library)

simple-date: date/time; not sure what it offers that local-time doesn't

split-sequence: Splits sequences based upon value or function of value

sqlite: sqlite3 interfacing

trivial-backtrace: tool for getting backtraces

trivial-utf-8: Portability for UTF-8

unicode: things like character classes for Unicode

usocket: socket library

utilities: utilities library

uuid: UUID library

1: wraps commonly available, but not standardized behavior in lisp
implementations: sockets, threads, debugger &c. often named "trivial-"

------
SwellJoe
I've had the same experience. I'd like to learn Rust, at some point, and I
read articles about it and tutorials now and then. But, realistically, I would
need to dedicate myself to it for a long period of time to be able to build
something from scratch in the language.

On the other hand, in a weekend of casual hacking, I was able to learn the
language (sort of) and make a project from scratch in Go that actually did
something useful. I'm sure the code is awful, and it'll take months of
weekends of casual hacking to be able to recognize why, but Go is damned near
comparable to Python or Ruby in terms of being able to go from zero to writing
working code.

I'll still keep learning a little rust here and there when I have some free
time. I'd really like to know a good, modern, systems language. I used to work
on some C projects, but C++ was just too daunting, it's just to big of a
language for casual use, so I never went down that path. Rust seems to be a
good compromise.

It's not even a "Go is better than Rust" situation; the Rust team has made
reasonable, occasionally brilliant, compromises on ease-of-use and ease-of-
learning vs their other hard requirements. Go just has different requirements
and they result in a language that is easier for new programmers.

------
foobar20198
Article makes a false premise: that speed of writing the first version is
important.

Much more time is spent maintaining software than writing the first version.
Some poor sob is going to have to go and fix all those "silly" mistakes that
were made and the bugs they caused (but of course, as we all know, they would
have been avoided if the programmer had just been a better programmer). Save
yourself (and us) the bother. Please use languages that stop you from shooting
yourself in the foot.

(Not that rust will avoid bugs, but it seems to catch a lot of stupid
"mistakes" before compile time. We're all humans and make mistakes, please
accept that fact before inflicting software on us.)

~~~
danjoc
>Article makes a false premise: that speed of writing the first version is
important.

In my experience, project managers care more about how long it's going to take
to build than about how maintainable it is. It's literally always the first
question they ask:

"How long do you think this will take you?"

I don't believe I've ever heard anyone in management ask, "How maintainable
will this be?" I'll ask around. I bet none of my peers have gotten that
question either.

~~~
tatterdemalion
Except that normally a new feature does not involve creating a new system.
Technical debt significantly impacts velocity of implementing new features in
the future.

------
siddhant
> Both languages seem to be competing for the same user base and they both
> seem to be "systems programming" languages, so there must be a winner,
> right?

Are they competing for the same user base? As far as I can understand, Go is
mostly being used in distributed software systems (like kubernetes) while Rust
is being used for more "systems" software where performance is critical (like
a web browser).

------
dhbradshaw
It seems like this could depend on what is already in your tool belt. If I
want productivity, I use Python. If I want raw speed and low overhead, there's
Rust. So Go ends up eclipsed on both sides.

~~~
skybrian
There's another dimension to this: how big is the codebase you have to
maintain? This is a "pets versus cattle" thing.

If you like artistically crafting small bits of code, Python may work fine. If
you're building something to last and need to shovel large amounts of code
around while migrating API's, a statically typed language with a fast compiler
will do more to help.

Python in the large is not very maintainable. I expect that a Rust codebase
will eventually be pretty nice to maintain, after the tooling matures more.
Currently, Go is probably easier, and quicker to write.

~~~
depressedpanda
> Python in the large is not very maintainable.

Could you elaborate on that?

I hear this a lot, but I work on a large Python project, and I don't think it
is hard to maintain. We do have some strict requirements, though:

1\. Test coverage; if it's testable there must be tests for it

2\. Type hinting; for large projects it's actually really nice to know at a
glance what the expected type is

3\. PEP8 & Pylint; how we write code should be standardized and easy for
others to read

~~~
skybrian
Well, (2) seems important and uncommon for Python in my experience, but it's
been a while. Maybe it's more common these days?

Here's the sort of scale I'm thinking of: consider a company with many teams,
many apps, and many shared libraries. Some of the apps and libraries won't
have anyone working on them, because it's generally not the case that a
company is willing to fund maintenance forever on everything; people need to
drop them for a while (to work on more important stuff) and someone else will
come back to them later. (This is being "walk-away friendly".)

Suppose you need to fix a security bug in a shared library and update all the
apps, most of which you haven't seen before. How easy is that to do?

------
wink
I've yet to see some Go code for typical CRUD web apps that doesn't look
roughly as elegant as 10-15 year old PHP code, if you know what I mean. I'm
not a real fan of ORMs and I'm surely not trying to badmouth PHP - but times
have changed and Rails did bring some things that inspired tons of web
frameworks in other languages to have cleaner, nicer code.

Open to suggestions for projects to take inspirations from so that my future
Go code will not be "quickly written AND it works AND it looks horrible" :)

------
thinbeige
Somehow this feels like apples vs oranges.

~~~
pgwhalen
Agreed. It's unfortunate that Go and Rust are frequently compared to each
other, they're not really trying to solve the same problems, they just
happened to be modern, hyped, backend languages. I don't blame this post
really, it's trying to correct that belief in a way. Rust is roughly a modern
C replacement, while Go is a modern Java replacement. ( _very_ roughly)

------
aaron-lebo
This'll be a fun comment section.

Maybe Go isn't so simply the answer, but the spread of "write everything in
Rust" or "Rust is the salvation of software" _is_ crazy. It's got huge
advantages but it's really a very difficult language for what it does. 80% of
software (nonsense percentage) that gets targeted to Rust would actually be
better in another language. Rust's focus is on (for most devs and software)
the wrong things.

It's too bad something like a better OCaml or Nim weren't what people were
going nuts rewriting stuff in but they don't have the mindshare. Rust
evangelism is like using a very advanced hammer to do everything. We've got
screwdrivers, chisels, and multitools, yall, use them! Is Rust actually the
right tool for the job? As programmers we do tend to seek the one true
language which doesn't really exist.

~~~
webkike
What are some program that Rust is not always a reasonable choice to write in?
Frankly, there may be some areas where another language is slightly easier to
program in than Rust, but I see the value in trying to promote a lingua franca
for programming. Different languages causes huge interoperability problems

~~~
aaron-lebo
I would argue almost anything. Nim writes like Python. The average programmer
never worries about lifetimes because there's a GC, which the vast majority of
programmers (especially application programmers) have gotten used to over the
last 40 years.

Rust is a big sidestep in usability, which makes sense if you want to replace
C and C++, but not much sense elsewhere. Humans are really, really good at
juggling multile languages, it's why we make a new one whenever we can.

~~~
sgift
If I can actually use a GC for my problem there is zero reason for me to
switch away from Java/Kotlin/JVM language: Great tooling, great ecosystem,
very mature.

So, the reason to use one of these languages is to get away from the "you can
use a GC"-space and then the count of interesting languages gets very small
very fast.

But sure, if your problem is in the "GC can be used" space, but you like to
use new languages .. go for it. It's certainly fun to use a new language to
tackle a problem. Just not the most efficient use of someones time in my
experience. (But: Fun!)

~~~
danieldk
_If I can actually use a GC for my problem there is zero reason for me to
switch away from Java /Kotlin/JVM language: Great tooling, great ecosystem,
very mature._

Unless you have a language with immutable data structures, ownership is still
a problem with a GC.

E.g. Consider the case where you have some class with some member variable.
You want to provide a getter to obtain the member. Now you have an ownership
problem: you could return a reference, but now the caller could mutate the
data structure in such a way that it breaks invariants of the wrapping class.
So, instead you return a copy, but this can be prohibitively expensive.

------
majewsky
I concur. I would really love to love Rust because it's a cool language that
values efficiency and safety, but in the end of the day, I keep writing Go
programs on all scales because it's just so productive.

------
Roritharr
I always look at programming languages from the same position i use to look at
guns. What kind would i want OTHERS to use around me?

From that POV Go wins hands down in my opinion. Harder to get wrong. Easier to
get right.

~~~
millstone
How is Go "harder to get wrong?" It's very easy to accidentally introduce a
null pointer dereference, data race, type assertion panic, or drop an error.
It's much harder to get these sort of bugs in Rust.

------
njetten
Took a look at both Rust and Go to hack on, but up until today I haven't found
a usecase where I _need_ C-like performance (and choose to use Rust).

Even though Google/Fuchsia is using Go for it's networking[1], I wouldn't
really consider Go to be a system language.

[1] [https://groups.google.com/forum/#!topic/golang-
dev/2xuYHcP0F...](https://groups.google.com/forum/#!topic/golang-
dev/2xuYHcP0Fdc)

------
BlackjackCF
I've been using Go in production for a little over a year now. I'm also
attempting to learn Rust in my spare time.

This post just about sums up my feelings on Go vs Rust.

------
CSDude
I code in Go for 2-3 years and tried to learn Rust for fun, but it was harder
for me. While Go is very simple and it has almost no barrier of entry, it
lacks much as well, Rust definetely looks more interesting and it would be
another enlightning experience.

------
kissgyorgy
Based on this article, I guess not a lot of developers need to program in Rust
nowadays.

------
pmm
> Predictable runtime behavior (zero cost abstractions and no garbage
> collector).

I see a lot of people considering Rust/Go because they are looking for
something much more modern than C++ and at the same time not running on JVM
due to the above

------
alekratz
I think this is a good answer. If you're really not in the mood to scratch
your head over confusing reasons for why your program won't compile while
learning the language, Rust is not what you want. While I have used Rust, I
have not used Go. Anecdotally, the consensus seems to be that it's relatively
easy to pick up, and get something done. And really, if you're just doing a
personal project, part of the point is to feel the Joy of Programming (TM) and
being able to make or learn something.

------
Lerc
If you need what Rust offers, use Rust. If you don't need those things there
are hundreds of languages that you could use(including Rust if you really
want)

------
red75prime
I use F# and Rust for personal projects. At work I deal with a programming
language akin to Go on the simplicity side, and it is just not fun.

But I am probably not typical. I'd no problems learning a language I'm
interested in (but Haskell. Monad pattern recognizer somehow can't take a hold
in my head for long).

------
baq
my take at a summary: use go if you want to do something, use rust if you want
to learn a _lot_ of important and interesting stuff that's been hidden from
you before doing something.

------
adamnemecek
> You'll need to unlearn bad habits and learn new concepts.

Ok, yeah, that's totz the way forward. Repost this if you are strong
independent developer who doesn't need no good engineering practices.

------
legendiriz68
"Safety against Null pointers, race conditions and all sorts of low-level
threats. Predictable runtime behavior (zero cost abstractions and no garbage
collector).

...yadayadayada...

If you don't require any of these features, Rust might be a poor choice for
your next project. That's because these guarantees come with a cost: ramp-up
time. You'll need to unlearn bad habits and learn new concepts. Chances are,
you will fight with the borrow checker a lot when you start out."

If you don't require...seriously is there any case ever in the world of
programming when you don't require those?

I can't even believe this article exists. Why would anyone ever use Go for
anything? It's the worst programming language ever invented. Yeah Im sure it
makes things fast just like jumping down from rooftop makes you go fast but
there is small side effect of dying.

------
holydude
I prefer Go's lacking to Rust's syntax and long compile times. But then again
I do not write things like Servo. I also like Nim and Crystal and while
Crystal's compile times are not ideal I can forgive this as i like the syntax

------
ivcha
yeah... no...

