13 ms·

> there's nothing for Go to be "strict about" Regarding memory management, sure, but Rust's strictness also handles things that Go doesn't. Two examples are er

by creata 6y ago

> there's nothing for Go to be "strict about" Regarding memory management, sure, but Rust's strictness also handles things that Go doesn't. Two examples are error handling --- Result<T,E> in Rust ensures that you check for errors before using a result --- and thread safety --- the borrow checker prevents many synchronization errors that Go doesn't catch.

tptacek 6y ago
I like Result<T, E> and would welcome its addition to Go, but the most surprising thing to me about switching from Go to Rust is that error handling is basically identical in practice; a little less typing in Rust, though you weigh that against Go's (weak but convenient) universal error interface. Rust gives a hard shove where Go gives something closer to a nudge, but in practice, Go's nudge (the requirement to do something with an error or else bear the shame of _'ing it) gets me 99.999% of the way to Result.
- saghm 6y ago
  > Go's (weak but convenient) universal error interface Rust has an `Error` trait too, and you can always just use `Box<dyn Error>` as your error type if you're fine with using a heap allocation to avoid caring about the concrete type (which is what's happening in Go when you use the error interface as your return type anyhow). Rust just makes the more efficient (in terms of runtime performance, not necessarily usability) the default and the more expensive option opt-in. This is a common pattern in a lot of the language design choices: performant by default, with the option to opt into a less performant variant to make things easier if you're okay with the cost. I think a lot of newcomers to the language (not saying you are one; I have no idea what your experience level is) don't realize this because the Rust community tends tends to _really_ like doing things the "proper" way. This isn't a problem per se, but I think there would be immense value in having more resources that made all of the options on the performance versus usability spectrum more clear.

by creata 6y ago

tptacek 6y ago

I like Result<T, E> and would welcome its addition to Go, but the most surprising thing to me about switching from Go to Rust is that error handling is basically identical in practice; a little less typing in Rust, though you weigh that against Go's (weak but convenient) universal error interface. Rust gives a hard shove where Go gives something closer to a nudge, but in practice, Go's nudge (the requirement to do something with an error or else bear the shame of _'ing it) gets me 99.999% of the way to Result.

saghm 6y ago
> Go's (weak but convenient) universal error interface Rust has an `Error` trait too, and you can always just use `Box<dyn Error>` as your error type if you're fine with using a heap allocation to avoid caring about the concrete type (which is what's happening in Go when you use the error interface as your return type anyhow). Rust just makes the more efficient (in terms of runtime performance, not necessarily usability) the default and the more expensive option opt-in. This is a common pattern in a lot of the language design choices: performant by default, with the option to opt into a less performant variant to make things easier if you're okay with the cost. I think a lot of newcomers to the language (not saying you are one; I have no idea what your experience level is) don't realize this because the Rust community tends tends to _really_ like doing things the "proper" way. This isn't a problem per se, but I think there would be immense value in having more resources that made all of the options on the performance versus usability spectrum more clear.