Hacker News Reader

Comment by bitwize | Hacker News Reader

Go handles it shitty, like the past five decades of computer science and PL design never happened. For imperative languages, exceptions are perfectly fine as a way to encode failure as part of the domain of operations. If you're in functional fantasy land, the correct approach is to use a Maybe monad or, better yet, an Either monad. But Go supports neither of these and that's one of many reasons why it sucks for modern development. In TypeScript you can do better and, for the sake of others who have to maintain your code, you should do better.

View on HN

> Go handles it shitty, like the past five decades of computer science and PL design never happened.

This has generally been my complaint with Go. Go is... fine. It offers a lot of features that seem revolutionary if you've never seen them before, but mostly feel like someone took the best parts of every language, and then implemented the least interesting aspects of those features.

- Interfaces are like typeclasses, but without actually offering any sort of higher-kinded polymorphism.

- Goroutines are kind of like Erlang processes, but without any notion of supervision and with shared mutable state.

- The error handling feels like it's trying to emulate an Either monad, but in a way that doesn't actually allow for the compositional properties that make an Either monad useful.

I know that Go's goal was never to innovate on language design, but I feel like it ignored a lot of low-hanging fruit in modern language design.

Obviously you can do worse than coding in Go, but for everything Go is good at, there's likely an even better tool for the job. I'm not convinced that there's any domain where Go is the best choice available, but it's definitely average at most jobs, and maybe that's where it finds its niche.

Edited: I had missed the word "higher-kinded" in front of polymorphism. Thanks donatj!

> Interfaces are like typeclasses, but without actually offering any sort of polymorphism

Can you explain what you mean by this? I certainly use them in a manner I would consider polymorphic.

You're completely right; I accidentally dropped the word "higher-kinded" in front of polymorphism.

Go's interfaces provide structural typing, which offers polymorphism over values. Typeclasses in comparison, offer polymorphism over types themselves. The distinction is subtle, but it drastically limits the sorts of abstractions that you can write with Go. In Go's defence, this is a limitation that even functional languages like F# and Elm face too. This sort of polymorphism is what makes ideas like monads and functors so powerful in a language like Haskell, and what causes those same ideas to lose some of their lustre in a less expressive language.

Unfortunately it's really difficult to find good articles on higher-kinded types, since anything written about them already assumes a ton of knowledge about the subject. This StackOverflow thread has some good insight though: https://stackoverflow.com/questions/21170493/when-are-higher...

It's entirely likely that in the real world these sorts of limitations don't actually matter, but my general frustration with Go stems from the fact that it's so close to being so much better than it is, and it saddens me that we as an industry chose to be so excited by something that's a tiny step forward, when there exist so many other options that are entire leaps and bounds forward.

Yeah, HKT is a godsend. It surprises me that Scala, one of the few languages that actually supports it, doesn't really use monads and all that good stuff in the base language. Like the fact that Scala uses duck-typing for the 'for' construct (it just looks for map, flatMap, filter) has always seemed odd.

The biggest mistake I think go made was not to include codes or domains. The error you get back is... a string. So you have to write tons of if statements just to return a bunch of errors you can’t handle.

Error is an interface. The default one may be a string but you can implement your open error with whatever extras you would like.

Right but then you need to use errors.as to match against it, rather than being able to do pattern matching. And there is no inheritance, no ability to generalize errors into a group.

You can totally just type assert your custom error type to check for it.

If it's the only type of error your method returns you don't even need to, just define your return type as your custom error type.

My experience with Go have been very positive. Once you get over the initial irritation of the error handling, I think it works perfectly fine. I have never been so productive as I can be when programming in Go. I’m sure there are technically better alternatives, but it has a very good balance between features, speed, standard library and multi platform support. At least for the backend server tasks I use it for. My biggest complaint has more to do with the new module system and tooling. The (not so) new Go Language Server is still very buggy and almost unusable in my opinion.

Using a Maybe type sounds a bit better, but not really that different than how Go does it in practice. The key decision is whether to throw errors or return them. Go's approach and the Maybe type are both variations on returning them.

The problem with returning them is it's tedious and you end up with error checking boilerplate everywhere.

The problem with throwing them is they're easy to ignore, and also you never know whether or not a function is capable of throwing an error, or what types of errors it can throw.

In conclusion, error handling sucks no matter how you do it :-/

Yeah, it does, but using monads to fold over errors is a lot nicer than what you have to do with Go.

Reply on news.ycombinator.com