Hacker News Reader

Comment by Thaxll | Hacker News Reader

I'm not sure I understand how this can happen in Go, it's a strongly type language, if for example you change a method / function signature, the code won't compile.

View on HN

Go is strongly typed (you can't pass an int to a function expecting a string), but its type system is not very powerful, and it cannot express many of the types people need in practice. Back to the discussion at hand (generics), Go programmers usually work around this lack by using interface{} types, which can point to anything and are essentially dynamic typing.

As another example, Go makes it impossible to create a Maybe/Option type which leads to a bunch of issues around returning failing or empty values from functions. In one particularly costly example, there was a function in a library that was getting some price information from a file. Originally this returned nil when the price information could not be loaded, but a refactoring caused it instead to return 0 which the client happily used. This was not caught for _weeks_.

What you're describing comes down to "Bad programmers do bad things", which literally no language can or will solve. If your code has lots of interface{} in it, you're not really using the language as intended. Pretty much every Go styleguide/linter/whatever will throw up at interface{} usage.

You can write unsafe code in Rust. Does that mean that Rust is bad too?

100% agree. Same with :any in typescript. When it comes to bugs... I tend to think that a good configured linter is more important than the degree of the type system. It’s nice to have a strong type system but people forget that a lot of programmers are bad and a good type system won’t change that fact.

>Originally this returned nil when the price information could not be loaded, but a refactoring caused it instead to return 0 which the client happily used.

Hard to feel sympathetic, as this practice violates the Go convention of adding an additional return value to the function to indicate failure, either of type error or bool, as appropriate.

>Go makes it impossible to create a Maybe/Option type

It's very much possible: https://play.golang.org/p/MCxGcZ-rJRU.

Of course, it's not generic, but I have a feeling that might change soon :)

The Option type there isn't type safe. E.g. https://play.golang.org/p/CiQLf4yWhCO doesn't throw a type error for the Get function even though I've omitted the null check.

Sorry, but that's just ridiculous. Obviously the language can't prevent you from defining your Option type incorrectly. The point is that it's not possible to misuse it.

Okay let me rephrase. The type checker doesn't make sure you've checked the value of ok e.g. you can do this: https://play.golang.org/p/x18Rh2iwd2E

Go constantly requires boiler-plate checks for errors, null values etc. without the type checker helping ensure you've checked for an error or null value.

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.

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.

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

Sounds like your company is just using a unidiomatic library. It's poor practice to return a zero value as an error instead of, well, returning the error. As someone else said, it's standard practice in the vast majority of all go code to return a value, error tuple and check at each call site. In fact, it's so common that it's the number 2 complaint about go code after not having generics (error handling too verbose).

Go has its problems, and it isn't a perfect language, but I have never felt unproductive using it. In fact, my company uses it for all backend services. It has a great stdlib and first class tooling. Most of the discussion in this thread seems to be coming from people who barely use it or have only dabbled with go.

As a tangent, it's really tiring to see HN engage ad nauseum in these pointless language debates. Every language has its place; use it when it's appropriate.

Reply on news.ycombinator.com