3 ms·

I've never seen those claims about heavy usage of empty interface in the real world, and in the few case we have it, there is type assertion that is safe and we

by Thaxll 6y ago

I've never seen those claims about heavy usage of empty interface in the real world, and in the few case we have it, there is type assertion that is safe and well known. As for the second example I don't think it's a language issue but more a programmer one, how Rust would have saved you in that case, anyone could have returned 0 for the price instead of a proper type. Using Rust doesn't magically turn programmer into good ones. You still have to know how to properly design your code and best use the language and its features. I'm often reading code in various language and I'm baffled at what a giant lib.rs looks like from someone that never really used Rust.

XorNot 6y ago
This is what strikes me: the situation is a programmer being lazy. They wanted to do: something(getPrice()), but if getPrice can actually fail the then either something needs to accept an error, or they need to handle the error. No type system imagined can save you from someone who's decided returning 0 is the correct way indicate an error in this scenario.
thedufer 6y ago
> how Rust would have saved you in that case, anyone could have returned 0 for the price instead of a proper type You've missed the problem that was posed. It wasn't returning 0 to indicate an error, it was changing the error value from nil to 0. In rust that would've been a type change (from Option<int> to int). Because the context here was about how stronger type systems (like rust's) allow you to be more specific about your types, and thus many code changes that would not involve the type changing in other more weakly-type languages do cause a type change in rust.
- eshyong 6y ago
  Except that in Go, you always return the error alongside the value, like this: return 0, errors.New("unable to get price") It's less elegant than Options but still, very common practice. GP's company clearly hasn't bought into Go if they're using a library that doesn't follow well-known conventions.

by Thaxll 6y ago

XorNot 6y ago

This is what strikes me: the situation is a programmer being lazy. They wanted to do: something(getPrice()), but if getPrice can actually fail the then either something needs to accept an error, or they need to handle the error. No type system imagined can save you from someone who's decided returning 0 is the correct way indicate an error in this scenario.

thedufer 6y ago

> how Rust would have saved you in that case, anyone could have returned 0 for the price instead of a proper type You've missed the problem that was posed. It wasn't returning 0 to indicate an error, it was changing the error value from nil to 0. In rust that would've been a type change (from Option<int> to int). Because the context here was about how stronger type systems (like rust's) allow you to be more specific about your types, and thus many code changes that would not involve the type changing in other more weakly-type languages do cause a type change in rust.

eshyong 6y ago
Except that in Go, you always return the error alongside the value, like this: return 0, errors.New("unable to get price") It's less elegant than Options but still, very common practice. GP's company clearly hasn't bought into Go if they're using a library that doesn't follow well-known conventions.