
Choosing Between Rust or Go? - psxuaw
https://dmv.myhatchpad.com/insight/choosing-between-rust-or-go/
======
krebs_liebhaber
This whole site reads like blogspam. The copy has that uncanny "SEO-optimized"
_je ne sas quoi_ to it, with a writing style halfway between "high-school
newspaper" and "coding interview cheat-sheet written by an Indian ex-pat",
using parts of the English language without understanding the underlying
meaning or where they fit in - like a script kiddie, but with natural
language. Does anyone else get the heebie-jeebies when they read "uncanny"
text like this?

~~~
skrtskrt
I just experienced this googling when particular 2021 car models come out,
hoping to find out what upgrades might be coming. There's a website for each
car with near-gibberish write-ups full of keywords that tell you absolutely
nothing.

And they're on the first page of google!

[https://www.2020lexus.com/car-
reviews-2019-2020/](https://www.2020lexus.com/car-reviews-2019-2020/)

First paragraph:

"Honda Civic is actually 1 of the most recent car that are designed by Honda.
This car is a sedan car hybrid of which are developed to be used for
metropolis car used."

~~~
codr7
Who needs actually translators when Google works enough well general used?

~~~
samvimes
Why waste time say lot word when few word do trick?

------
kristoff_it
So when I wrote my piece complaining about how people should not try to
compare Go and Rust as they were created for very different purposes, people
kept commenting that I was attacking a problem that I had came up with myself,
and yet here's one more comparison of that kind reaching the front page of hn.

To me the question in the title is as ill posed as would be "Choosing Between
C or JavaScript?".

~~~
sramsay
Your problem is that you're not a Thought Leader whose Insights are being
brokered by a Community Engagement Specialist.

And let me explain. This guy has been "at a startup" and "at a Golang Meetup."
If that isn't thought leadership, I don't know what is.

~~~
Animats
_Your problem is that you 're not a Thought Leader whose Insights are being
brokered by a Community Engagement Specialist._

Good point.

It's a very light article, written for people who listen to Thot Leaders. It
misses most of the important points.

Go is designed for web back ends. It has all the stuff you need for that, and
the libraries have been thoroughly pounded on and debugged, because Google
uses them internally. The language is stable and doesn't change much. It's a
good fit to that job.

For other applications, Go may or may not be a good fit. Desktop apps?
Probably not. Games? Probably not. Real-time control? No.

Rust now seems to be trying to use every cool idea around, all at once. The
borrow checker was brilliant. The added cruft, not so much. We have generics!
We have type theory! We have lambdas! We have functional programming! We have
threads! We have futures! We have async! We have a whole bunch of different
HTTP libraries! We've changed the error handling system how many times now?
It's all very cleverly done. But it's overdone. I'm out of that world, and not
clear on whether there are signs of it settling down yet.

~~~
heavenlyblue
The issue with Rust is that people actually like using it. So there’s a bunch
of development happening purely for enjoyment: why is that an issue? Nobody’s
forcing you to keep up with the trends - just stick to the older versions of
the libraries and it’ll simply work.

~~~
Animats
Is there a winner in the HTTP Rust library wars yet? The last time I used
Rust, Hyper was on top, but I hear it's no longer cool. "reqwest" is being
talked up. You can also get several versions of the same library in the same
program through dependency problems.[1]

This is a process problem. The development process for Rust does not seem to
force convergence.

[1] [https://hackernoon.com/programming-in-rust-the-good-the-
bad-...](https://hackernoon.com/programming-in-rust-the-good-the-bad-the-
ugly-d06f8d8b7738)

~~~
jamwt
It's... been hyper for years and is still hyper. Reqwest is an ergonomic
wrapper on top of hyper if you want a higher-level API with less control.

Among the Rust ecosystem things to gripe about, this is a odd one.

async_std vs. tokio is the real split-investment battleground these days,
effectively undermining the async/await momentum right as it gets out of the
gate.

------
jtsiskin
Note that the section "Fuschia: Google’s Successor to Android" is incorrect.
The [Fuchsia Programming Language
Policy]([https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master...](https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/docs/project/policy/programming_languages.md))
states neither Rust nor Go is not supported for end-developers.

~~~
OrderlyTiamat
> states neither Rust nor Go is not supported for end-developers

Just for clarification, neither are supported according to the linked
document. (the double negative was confusing for me)

~~~
jtsiskin
Oops you're right - too late to edit it. It should say "neither Rust nor Go
are supported for end-developers"

------
bestouff
Initially my take was Javascript is for quick-and-dirty code, Rust is for
beautiful thought-out architectures, and Go is somewhere in the middle.
Nowadays I tend to do even quick hacks in Rust.

~~~
winrid
I've written well engineered code in JS, I think it just requires a lot of
discipline because the runtime doesn't help you.

~~~
dan_quixote
It's not that it's impossible, it's just that expectations are generally low
when it comes to JS code quality.

~~~
winrid
Who sets their expectations low? :)

------
Scuds
My general file card on Rust's appropriateness:

It's for anywhere you want an iron grip on memory and correctness and the cost
of screwing up is very large and don't need a quick minimum viable product.
You'd expect to be writing a database or a high availability proxying server
or any kind of driver or a game engine

------
ferest
Go is more like a faster python or lighter java, rust is more like C/C++, they
aren't comparable

~~~
verify_sirrah
> Go aims to combine the safety and performance of a statically typed compiled
> language with the expressiveness and convenience of a dynamically typed
> interpreted language. It also aims to be suitable for modern systems
> programming.

\- Rob Pike

[https://web.stanford.edu/class/ee380/Abstracts/100428-pike-s...](https://web.stanford.edu/class/ee380/Abstracts/100428-pike-
stanford.pdf)

edit: To provide greater context from the slides I linked. Go was designed to
replace C++ and Java in Google.

~~~
tandr
> To provide greater context from the slides I linked. Go was designed to
> replace C++ and Java in Google.

Was it successful in this task?

~~~
apta
Far from it in fact.

------
christiansakai
I like both, why not both? They are created for different purposes.

------
apta
> Go probably is a better successor to Java since it’s useful for building
> distributed systems.

Far from it. golang, both the language and the ecosystem offer nothing close
to what Java (and the JVM) offer in terms of building reliable systems,
monitoring, profiling, performance, etc. Sorry to say, the fact that this
comparison was made in the first place shows lack of experience.

------
marcrosoft
I don't know Rust but Go:

* Go is an extremely productive language * It doesn't have all the fancy cool features other languages have * The community is huge and it is easy to find libraries * It has gained popularity faster than any other language I can think of. They must have done something right.

~~~
tandr
I would agree for all of them. But, from personal experience - productivity
dives down really badly the moment code base have grown in size considerably.
Adding more people makes it even worse, since most of these people start to
come in with a very fresh language knowledge ("oh, Go is simple, you can pick
it up in no time --management"), and you have to babysit each merge request
carefully. Which makes your productivity worse, mgmt adds more people, you
miss things here and there, and code quality goes down.

------
hsnewman
My only complaint about go is the lack of a Go supported IDE. There are lots
of paid ones out there, but I've spent the morning looking for a good one that
runs in a web browser that are easy to install.

~~~
guessmyname
> _My only complaint about go is the lack of a Go supported IDE. There are
> lots of paid ones out there, but I 've spent the morning looking for a good
> one that runs in a web browser that are easy to install._

I am not sure why would you want to run your IDE in a web browser, but Visual
Studio Code [1] is regarded by the Go community as one of the best code
editors (with plugins) [2] to develop Go projects, and in case you do not know
already, Visual Studio Code is technically a web browser [3]. That being said,
Goland [4] is probably one of the best integrated development environments for
Go programming out there.

[1] [https://code.visualstudio.com/](https://code.visualstudio.com/)

[2]
[https://code.visualstudio.com/docs/languages/go](https://code.visualstudio.com/docs/languages/go)

[3] [https://github.com/microsoft/vscode](https://github.com/microsoft/vscode)

[4] [https://www.jetbrains.com/go/](https://www.jetbrains.com/go/)

~~~
bdcravens
Plus if you want VS Code in the browser there's Coder.com (both hosted and
open source varieties)

------
fdghfg
tl;dr Go, of course. rust it just too fugly and has no worthy support on
windows and in IDEs. sure, you may love it but if you check out jobs, it's
like 100:1 for Go. rust is and will be an exotic language for very niche use
cases.

let the downvotes begin :)

~~~
sfkdjf9j3j
What kind of problems with IDEs are you running into with Rust? I've used
Intellij and Clion with the Rust plugin and they seem to have all the standard
IDE bells and whistles - inferred type annotations, autocomplete, autoimport,
interactive debugging, refactoring, etc. I haven't tried VSCode but from what
I understand that's even more popular than the Jetbrains tools so I would
guess that it works pretty well too.

------
zerr
I've abandoned Go in the middle of The Go Programming Language. There is
really no reason to use it - there are much better languages for systems (both
- as in services as well as in low-level systems) development. Desktop
development experience is quite a mess as well.

~~~
skrtskrt
I've been starting up using Go as "fast Python" for web services / REST APIs.
The patterns encouraged by Go development are actually how I preferred to
write Python in the first place, which is to say

1\. largely avoiding huge tightly-coupled frameworks like Django

2\. writing a little more boilerplate with the payoff of making code a lot
clearer to reason about without having to step through tons of layers of
overly-dynamic libraries

I think Go will really start to eat up the backend web services space in the
coming years.

~~~
whateveracct
In this vein, I've been focused on finding/creating tooling at the same level
of abstraction as Go (net/http, database/sql + sqlx, etc) but in Haskell. So
it ends up being a bit more ergonomic for a variety of reasons.

scotty (-> net/http), aeson (-> encoding/json), and postgresql-simple (->
database/sql) are pretty close, although aeson & postgresql-simple need some
tooling on top to get them on par w/Go struct tag reflection imo.

I still love to use more advanced Haskell libraries, but there's something to
be said for stitching together functions in IO with simple types.

~~~
creyes
I think you're right that the level of abstraction is the same but the
language ergonomics are drastically different. Go was designed so that anyone
coming out of school could read/understand/write it very quickly. I'm not a Go
expert and I can reason about code pretty well and even write some stuff.

That's absolutely NOT true of Haskell. It's a much more nuanced language and
while I'm sure it's great once you learn it, the learning curve is steep.
Because of that I think it's much easier to hire Go developers than Haskell
developers too

~~~
whateveracct
Optimizing for the beginner isn't necessarily a good thing though. While that
is true of Go, the trade-off is for even somewhat complex systems, Go starts
to falter compared to Haskell. Local reasoning of Haskell scales nicely with
complexity, at the cost of learning it.

There are economics at play here too. If your turnover rate is high (1-2 years
even), the company can get the short end of the stick, while the employees get
to pay the fixed cost of learning Haskell on company time.

My experience though is FP novices can get to doing new-hire-level tasks in
Haskell within a couple weeks of mentorship. I've seen 0-FP-experience interns
dive into applicative functor code in _Scala_ and have no trouble so long as
we sat down and explained things from first principles (and motivated the
value of the abstractions we use.)

I have actually found the opposite to be true for hiring. Every place I've
worked has had more Haskell applicants than they knew what to do with. Largely
because Haskell can make your company uniquely desirable in a sea of options.

The only time a Haskell company I worked at "had trouble hiring" was when we
turned away countless Haskell-experienced developers due to the sole veto of a
VPE over and over again. After months of observation, it was clear that he was
actually starving the team of Haskell resources so he could build momentum to
move away from it (despite the team being fine with the language)

~~~
apta
> Go starts to falter compared to Haskell.

Not just Haskell, but any mature OO language/runtime as well (JVM, .NET). The
fact remains that golang is popular because of Google's name behind it. While
its concurrency model is somewhat decent, its warts get in the way very
quickly for any non-trivial project.

~~~
hactually
what do you define as non-trivial? I'm aware of a number of companies and
projects that are definitely more than non-trivial.

I think Java/C# are verbose and ineffectual languages and people are seeking
alternatives that make a lot more sense and deliver more power and speed.

