Comment by Thaxll | Hacker News Reader

Comment by Thaxll | Hacker News Reader

Parent Full thread

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.

> 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.

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.

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.

Reply on news.ycombinator.com