9 ms·

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding.

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they weren't too happy with it. For weeks (literally) i mulled it over, i really really really wanted to use Rust. Rust gives me a peace of mind that Go never came close to. Unfortunately, Rust does not fit the development speed nor developer experience[1] that this shop has.. and i really felt Go would be the best choice for this place. My point to this post isn't to make a Rust vs Go comparison.. but rather, a wishlist for the hopefully eventual Go 2.0. I have no idea if/when that will ever be made.. but i hope it will, and i hope they adopt some things from Rust. 1. Channels without panics. Channels are awesome, but Go's design of them means that you have to learn special ways to design your usage of channels so that it does not crash your program. This is asinine to me. So much type safety exists in Go, and yet it's so easy for a developer to trip over channels and crash their program. 2. Proper error handling. I love error checking - i love it in Rust especially. It's very explicit, and most importantly, very easy to check the type of things. Recently i was reading an article about Go errors[2] and it made me realize how messy Go errors are. There are many (three in that article) ways to design your error usage, and worst of all your design doesn't matter because you have to adapt to the errors returned by others. There is no sane standard in use that accounts for the common needs of error checking. 3. Package management. It's a common complaint, i know. But Rust & Cargo is so excellently crafted.. Go just got it wrong. Recently i've been using Glide, and while it's a great tool, there is only so much it can do. It's a tool built to try and put some sanity in a world where there is next to no standardization. We need a Go package manager.. hell, just copy Cargo. 4. Enums. My god, Enums. Such a simple feature, but so insanely welcome and useful in Rust. You'll note that i didn't list Generics. I know that's high on peoples list, but not mine. To each their own.. please don't start a holy war. (this is likely due to me using Go for ~4 years. I'm quite comfortable without Generics) [1]: By experience, i mean what they desire/expect. They're a Python shop after all, i didn't want to make a choice that would cause them to spend weeks/months feeling unproductive. [2]: http://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully http://dave.cheney.net/2016/04/27/dont-just-check-errors-han... edit: minor text fixes.

Manishearth 10y ago
A lot of this comment resonates with my experience and views :) > You'll note that i didn't list Generics. I know that's high on peoples list, but not mine This is me too. Been programming in Rust for 3 years, and picked up Go two years ago. I like the language; I like how it feels like "C but safety net". I haven't used it for anything important (course projects a bit), but this is because so far Rust works for almost all my needs and for everything else I use Python. But I'd be happy to use Go if someone asked me to or there was a reason why Python wasn't suitable. However, generics aren't what I want in Go. I get that a language without generics can get complex and perhaps slow to compile and has other issues too. On the other hand, enums are on the top of the list for me. Especially for the message-passing programs I tend to write in Go. There have been times when I've hacked together an enum system using interfaces and hidden methods but its not great. I've grown to get used to error handling, but I do think it can be improved a lot. Package management was a major gripe of mine but it seems like y'all are fixing that :D I have not written production software in Go so panic-proof channels haven't been on my radar but yeah, that one makes sense. > didn't want to make a choice that would cause them to spend weeks/months feeling unproductive. +1 I have often recommended Go to people who don't have time but want to learn something new. If you want to actually spend time writing software from scratch in week 1 of learning the language, Go is amazing. I recommend Rust often too, but I usually find out how much time they have and/or their background first. > Rust gives me a peace of mind that Go never came close to. Again, big +1. For me it is two effects -- one is that Rust feels safer, and the other is that as a Rustacean Go feels wasteful at times. After programming in Rust for that long, losing performance at any corner for no reason irks me. In Rust, for example, most folks will avoid reference counting and trait objects and heap allocation as much as possible. If you see an unnecessary trait object it _feels wrong_. This is a perfectly sensible attitude to have in Rust. For me, it often carries on into Go. But Go loves interfaces and has garbage collection (with good escape analysis, but a GC nevertheless). Every time I use an interface object in Go, it _feels wrong_. It shouldn't. And I've learned to ignore it -- if I'm writing an application in Go; perf probably didn't matter enough for this to matter. (In fact, the odd unnecessary trait object in a typical Rust lib is usually no big deal either.). But, that nagging feeling is still there :)
- 10y ago

Manishearth 10y ago

A lot of this comment resonates with my experience and views :) > You'll note that i didn't list Generics. I know that's high on peoples list, but not mine This is me too. Been programming in Rust for 3 years, and picked up Go two years ago. I like the language; I like how it feels like "C but safety net". I haven't used it for anything important (course projects a bit), but this is because so far Rust works for almost all my needs and for everything else I use Python. But I'd be happy to use Go if someone asked me to or there was a reason why Python wasn't suitable. However, generics aren't what I want in Go. I get that a language without generics can get complex and perhaps slow to compile and has other issues too. On the other hand, enums are on the top of the list for me. Especially for the message-passing programs I tend to write in Go. There have been times when I've hacked together an enum system using interfaces and hidden methods but its not great. I've grown to get used to error handling, but I do think it can be improved a lot. Package management was a major gripe of mine but it seems like y'all are fixing that :D I have not written production software in Go so panic-proof channels haven't been on my radar but yeah, that one makes sense. > didn't want to make a choice that would cause them to spend weeks/months feeling unproductive. +1 I have often recommended Go to people who don't have time but want to learn something new. If you want to actually spend time writing software from scratch in week 1 of learning the language, Go is amazing. I recommend Rust often too, but I usually find out how much time they have and/or their background first. > Rust gives me a peace of mind that Go never came close to. Again, big +1. For me it is two effects -- one is that Rust feels safer, and the other is that as a Rustacean Go feels wasteful at times. After programming in Rust for that long, losing performance at any corner for no reason irks me. In Rust, for example, most folks will avoid reference counting and trait objects and heap allocation as much as possible. If you see an unnecessary trait object it _feels wrong_. This is a perfectly sensible attitude to have in Rust. For me, it often carries on into Go. But Go loves interfaces and has garbage collection (with good escape analysis, but a GC nevertheless). Every time I use an interface object in Go, it _feels wrong_. It shouldn't. And I've learned to ignore it -- if I'm writing an application in Go; perf probably didn't matter enough for this to matter. (In fact, the odd unnecessary trait object in a typical Rust lib is usually no big deal either.). But, that nagging feeling is still there :)

10y ago