Show HN: Rust vs. Go – What are your thoughts?
7 comments
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.
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.
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.
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.
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.
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.
> 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.
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.
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...
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...
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.
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.
I think the syntax of Rust isn't very appealing, but that's not a good reason to /not/ look at it.
Convince me? :)