How does your team (E.g., the people on the hook for reviewing/supporting/contributing to your project) feel about the change?
This is a big difference when moving from Go. A language that nobody calls beautiful, but is very easy for a team to contribute to and support (relative to other languages).
I don't think that's fair. I'm not entirely sure what beautiful means for a programming language, but I've seen many examples of Go programs which exhibited a beautiful simplicity. This project for example: https://github.com/inconshreveable/slt.
I think it’s different kinds of beauty. When I write Go, my good programs are “beautiful” for how simple they are; it’s relatively difficult to over-abstract. It’s the rugged practicality.
The other kind of beauty is a quest for an abstraction that makes everything conceptually simple—once you understand the abstraction. It’s more of a mathematical elegance thing, and it’s just gravy if it happens to solve a real world problem.
Yes I agree. Beauty is highly subjective when it comes to programming languages. Its definitely an expression of a feeling from use and relative successes/failures.
I know people I highly respect that call C# with Linq & its lambda implementation very beautiful, and I can see why, but I have not a strong opinion one way or another on it.
I had a lot fun when initially learning Rust, and the way I have phased it in to the projects (work & home) that I have been doing has led to successes, which definitely increases my bias towards the fact rust is awesome =).
Like I said, we are using it for new code bases, and not moving all of our existing Go Code, thats doing fine. I agree that GO is very easy, I can get most any dev up and running and comfortable on Go in about a week. Honestly though, I can get a decent dev going on Rust in a week. Even with Go, if I was teaching a NodeJS dev, I would get them going on everything but goroutines & channels, and then ease them into it. With Rust, I feel to a Go dev, the syntax isnt too foreign. Plus, focus on understanding ownership & borrowing with real examples relevant to the team, then have them focus on core language features, and then branch out, how you would do with any language. We see a noticeable uptick in performance, and Rust has been well received.
Yes Go's ecosystem now is well established, but when trying to do Location intelligence software back in 2014/2015 with Go was a pain from memory. I am not bashing GO, been a gopher for a while, but I do love Rust, and IMHO is not too complex. It just makes sense.
One more final point while I was thinking. I am a fan of both languages, Go & Rust. Go is in-fact still my recommended languages for teams, and until Rust hits a maturity level that wont change, but I am a big fan fo what rust is trying to become, I am using it for new code because of the problem fit, and I believe both ecosystems can co-exist. Go is also introducing some nice long awaited features (hopefully) in a decent way.
One more point here, I wouldnt have done it if I did not get full support & enthusiasm from my team. But I guess sometimes it helps when you dont have HUGE existing code bases to have to justify to port. =)
This is a big difference when moving from Go. A language that nobody calls beautiful, but is very easy for a team to contribute to and support (relative to other languages).