
Why Rust and Not Go: A Rebuttal - codesections
https://blog.juliobiason.net/thoughts/why-rust-and-not-go/
======
boyter
Really who cares?

Pick a language. They are both fine. Both will probably solve whatever problem
you have without too many issues. Arguing over which one you should use its
probably pointless 99% of the time.

I wish I had a link to the twitter exchange between both accounts where the
answer they both agreed with was learn both, and lets have this conversation
in a week. It feels 100% relevant here.

~~~
bad_user
> _learn both_

This is a common advice but it isn't realistic.

It takes a lot of time to learn a language, its tools, its most popular
libraries, its best practices, to interact with its community, to see in what
problem domains it shines, etc.

I'd say you need to give it more than a year, more than two if you're not
doing it on the job. You can churn code much sooner than that obviously,
that's not what we are taking about.

Nobody does that to see which language is best. And those that do are doing it
superficially, writing a hello world or two and then jumping to conclusions.

This advice basically makes no sense and yet people keep repeating it.

------
bad_user
Not sure how good the original article is, but this is a poor rant.

And I very much dislike Go as a language.

~~~
sparkymat
Agreed. The original article made a good point of the language being simple
(feature-light) makes it appealing for enterprises, as an alternative to Java,
for building enterprise solutions. Go is easy to pick up and the language is
opinionated, forcing teams to adhere to a uniform way of doing things.

I was interested in a rebuttal which would address these points. Instead, it
comes across as just addressing the points in the article as an attack on
Rust.

------
comex
> > The Go compiler is fast.

> Ah crap, not that shit again.

> The whole point is "compiler is fast, tests run faster". Well, what if I
> said the compiler would catch bugs before the tests? That would be even
> faster, 'cause then you can focus your tests on system behaviour, which is
> way more important than function behaviour or class/structure/module
> behaviour.

No.

A fast compiler is not only good for unit tests. And even when it comes to
unit tests, it is not at all idiomatic Rust to omit them; on the contrary,
unit test support is built into the language!

Rust having a slow compiler is a serious downside. The language has many
upsides that can hopefully make up for it, depending on your priorities, but
that doesn't make compilation speed a non-issue.

That said, the compiler is significantly faster than it used to be and
hopefully will continue to improve as time goes on.

------
illuminati1911
I don't understand how these 2 languages always get into these comparisons.

They are mostly aimed for different audiences and different purposes.

------
im_down_w_otp
They're just fundamentally for different things. For most classes of problems
where the distinct features of one or the other would make any difference, if
you're choosing between Rust and Go, then you may consider that you might not
entirely understand either your problem and/or why either of these should be
considered as part of a solution.

We chose Rust for a bunch of reasons related to enabling high-assurance
software development with better ergonomics & efficiency than attempting to do
the same with C and bolting a bunch of disjointed augmentations onto either it
or its toolchain.

Substructural type system + HM type system + ease of integration into embedded
targets is fantastic for the platform we're building and the markets we're
addressing. Using Go would make no sense at all for us, but may be perfect for
a use case where the same kinds of guarantees & assurances aren't necessary.

------
apta
> > As I already mentioned, Go was created to solve Google problems, and
> Google problems are definitely enterprise-scale problems.

> You know who has Google problems? GOOGLE! You know who else has Google
> problems? NO ONE!

That's true, but guess what, Google still uses C++ and Java for the vast
majority of its critical infrastructure. So even at Google, C++ and Java reign
supreme at handling "Google scale". And it's not surprising really, the
maturity, performance, tooling, etc. available for Java and C++ are far
superior to what golang has to offer. Not to mention both being far better
languages than golang (even with how complex C++ is). golang is a weak
language not suited for modeling complex domains.

Secondly, golang was developed by some employees at Google, not Google itself.
And if it weren't for the brand name behind it, it would have gone nowhere.

------
netsec_burn
> Honestly, I haven't seen -- even with Rust -- something as dead simple as
> Flask

What about warp?
[https://github.com/seanmonstar/warp/blob/master/README.md](https://github.com/seanmonstar/warp/blob/master/README.md)

------
odkamkfn
I don't like the aesthetics of rust as a language, and I don't like the
behavior of certain members of the rust community who vacillate between
overzealous evangelism and dismissive rudeness.

------
nirui
As far as my understanding goes, I see this kind of comparisons as a "Please-
consider-to" list to the language teams.

I'm a heavy Go user and light Rust user. I enjoy them both, and they gives me
different set of advantages in return.

Please, don't use/treat comparisons as an attack, make it "So-this-can-help-
me-do-that".

------
surfsvammel
I totally see what the author of this post is saying, and I agree with
most...But, that original post wasn’t half bad. It was entertaining and well
written. I frankly don’t think anyone took it for anything other than an
opinion piece.

