Hey, I don't really view Go and Rust as being in any real sort of competition as they do different things and are oftentimes complementary. That said, I happen to have a strong dislike of Go for several reasons and fancy Rust quite a bit. It puts me in an odd position at work, sometimes as "the Rust guy" who simultaneously "doesn't like Go" and so I wish to ask for the views, thoughts, and insights from others.
What do you think about Go and Rust or, more directly, Go vs Rust?
To me it feels like they come from different views on what makes language "maintainable", while being somewhat close in usual applications - maybe it really isn't as much of a language competition as it is competition of different "schools of thought"
At work I feel I'm in that position as well. We use Go extensively and many of my fellow developers love Go, while I'd much rather use Rust.
To be honest though, I don't think we'd really play to either language's strengths (we write micro-services for an online payment system, HTTP/JSON, SQL DBs, logging, integration with (a few) AWS services, ...). However, I believe Rust would allow us to express intent more clearly and structure error handling better, despite all the "noise" caused by borrowing/string-type-conversions, etc.
despite all the "noise" caused by borrowing/string-type-conversions, etc.
It feels like people often miss the fact that borrowing only needs to be extensively used when sharing something - you can just as well just use owned structures and clone where applicable, as you would do in higher-level languages
Though yeah, it would be really nice to have owned string literals
That "noise" comment should be read very contextually. In our context efficient memory management isn't at the top of the list of what's important; due to many libs being written with memory efficiency in mind it becomes "noise" to us.
I understand the noise remark better now that you put it in perspective. I'm also not in the "we need memory efficiency" boat but I am in the "we need correctness" boat and I find that the strictures of the compiler for things like data reuse and sharing make it very attractive. Rust's error handling is far superior to the if statements which are seemingly needed for every function call in Go, and the complete absence of functional programming in idiomatic Go seems like another step backwards. I have a low opinion of Go relative to Rust.
One of the hardest things to get across has been the safety and error handling constructs in the language. As you say, it's a heck of a trick, right? Anyway, the ability to do things like the typestate pattern is just mind-blowingly helpful. However I struggle to highlight the problems with Go to a bunch of C veterans who believe in many of its design principles. They have tremendous nostalgia for C as "the good old days" and generally don't internalize its dangers and failings.
As a side ntoe: One colleague in particular went from a Scala fan to a Go fiend and I'll always struggle to understand how that could happen with Rust laying around. Peculiar.
Hey, I don't really view Go and Rust as being in any real sort of competition as they do different things and are oftentimes complementary. That said, I happen to have a strong dislike of Go for several reasons and fancy Rust quite a bit. It puts me in an odd position at work, sometimes as "the Rust guy" who simultaneously "doesn't like Go" and so I wish to ask for the views, thoughts, and insights from others.
What do you think about Go and Rust or, more directly, Go vs Rust?
To me it feels like they come from different views on what makes language "maintainable", while being somewhat close in usual applications - maybe it really isn't as much of a language competition as it is competition of different "schools of thought"
At work I feel I'm in that position as well. We use Go extensively and many of my fellow developers love Go, while I'd much rather use Rust.
To be honest though, I don't think we'd really play to either language's strengths (we write micro-services for an online payment system, HTTP/JSON, SQL DBs, logging, integration with (a few) AWS services, ...). However, I believe Rust would allow us to express intent more clearly and structure error handling better, despite all the "noise" caused by borrowing/string-type-conversions, etc.
rust-joy-go-no-joy.jpeg
It feels like people often miss the fact that borrowing only needs to be extensively used when sharing something - you can just as well just use owned structures and
clonewhere applicable, as you would do in higher-level languagesThough yeah, it would be really nice to have owned string literals
That "noise" comment should be read very contextually. In our context efficient memory management isn't at the top of the list of what's important; due to many libs being written with memory efficiency in mind it becomes "noise" to us.
I understand the noise remark better now that you put it in perspective. I'm also not in the "we need memory efficiency" boat but I am in the "we need correctness" boat and I find that the strictures of the compiler for things like data reuse and sharing make it very attractive. Rust's error handling is far superior to the
ifstatements which are seemingly needed for every function call in Go, and the complete absence of functional programming in idiomatic Go seems like another step backwards. I have a low opinion of Go relative to Rust.:100:% - I would actually say that error handling in Rust is better than in most "fully" functional languages, including Haskell
Yes, I've some conflicting thoughts on it still. Rust is a bit of a one-trick horse when it comes to error handling. It's a _very_ good trick though!
So far my impression is that it's enough, and it fits _me_ and how I approach solving problems in code.
One of the hardest things to get across has been the safety and error handling constructs in the language. As you say, it's a heck of a trick, right? Anyway, the ability to do things like the typestate pattern is just mind-blowingly helpful. However I struggle to highlight the problems with Go to a bunch of C veterans who believe in many of its design principles. They have tremendous nostalgia for C as "the good old days" and generally don't internalize its dangers and failings.
As a side ntoe: One colleague in particular went from a Scala fan to a Go fiend and I'll always struggle to understand how that could happen with Rust laying around. Peculiar.