
Show HN: Rust vs. Go – What are your thoughts? - mrburton
I personally haven&#x27;t event used or looked at Rust so I don&#x27;t have an opinion. So now I&#x27;m interested hearing what others think?<p>I think the syntax of Rust isn&#x27;t very appealing, but that&#x27;s not a good reason to &#x2F;not&#x2F; look at it.<p>Convince me? :)
======
smt88
Lots has been written about this topic already. There are long blog posts with
code samples that would be hard to reproduce on HN.

I suspect this will turn into a flamewar fairly quickly, but my 2 cents is
that Rust has a much steeper learning curve in every way, but it's more
ergonomic in the long-run.

Other people will rightly suggest using the right tool for the right job. I
just don't happen to do work that makes sense in Go.

------
notheguyouthink
Go is my daily driver. With that said, I _love_ Rust. I even tried to switch
my team to Rust for a short while, and used it as my main personal language
for ~8Mo or so. My decisions to stick with Go were mainly the following:

1\. For work, my team just wasn't going to switch to Rust. From a Python shop,
Go has enough pushback. Which tells you a lot about my shop lol. I'm still
holding out for Rust on a future project that I think can't be Go, and has to
be Rust.

2\. For work and home, Go just feels easier and faster in mental overhead with
the exception of one thing[1]. Which ultimately means if I need to blindly
program my way through a vague feature description, and then find out it's way
different than they said, it's easier to refactor and retroactively fix a bad
design in Go than Rust.

3\. For work and home, Rust had a terrible dev UX when cross compiling HTTPS.
I was trying to cross compile my HTTPS Rust binary, an easy task in Go, and in
Rust it was a massive headache. In Go it's an afterthought. This will improve
in time I'm sure, but the easiest solution in Rust was to not do it, compile
on the platform it's running on.

[1]: As said, I find Go to have less overhead than Rust; Except, for any type
of optional value. Go's lack of enum types and Rust's Option<> is a huge blow
for me. I absolutely love Option in Rust.

------
jstewartmobile
They did a good job on it. I'm just not a big fan of the "zero-cost
abstractions" approach for typical programming tasks. In those cases, it's
just over-complicating things for premature optimization. And the compiler is
slow as molasses--which really takes a lot of fun out of the workflow for me.

Also think a lot the popularity comes from social factors rather than
practical considerations. It's like an "I fought the borrow-checker, and won!"
t-shirt for your resume. The guys writing Redox--yeah, that's a practical use
for Rust. The guys writing web frameworks in it... no comment.

~~~
smt88
> _it 's just over-complicating things for premature optimization_

1) I don't really understand how an abstraction can be premature optimization,
unless you mean "optimization" in the human sense -- optimizing the coder's
time instead of the machine's resources.

2) Rust was invented to rewrite a major web browser... so it wasn't premature
optimization for its original intended purpose/users. They knew what they were
going to need.

~~~
jstewartmobile
1) The coder's time is definitely part of the equation. The zero-cost approach
adds more to the cognitive load (and the syntax) compared to a GC language
where you can just allocate-and-forget.

2) Other part of the sentence was "typical programming tasks." Browser dev is
fairly rarified compared to things like webapps, CRM, embedded, etc. It's like
every kid today has Rust on his resume, but when I look at their work history,
they've never even pushed the performance boundaries of Python...

------
siscia
Learn a new language make sense if such language teaching you a new way of
thinking.

If you come from a "normal" background I guess you can already program in
python or ruby or java or C

From this kind of background I would love towards functional programming
(Haskell or Closure) or the actor model (BEAM languages or maybe pony) or
Rust.

The reality is that go forgot the last 10/20 years of progress in programming
languages theory. It is true that this makes a really simple programming
language but it is also true that the complexity of any task does not
disappear if you use a simple programming language but it will be simply
shuffle around in the code itself.

On the other side rust is pushing the state of the art in programming
languages. This means that the language itself is more complex to learn, but
once you master it the language itself will take care of part of the
complexity in your code.

As always it is a trade-off.

