Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

I think you have to be very careful before claiming readability gains from fewer lines of code. I've done a lot of Python programming and for simple things like mapping a single function over a list, a list comprehension or generator expression can indeed be a tiny bit more readable than a for loop, but combining that with some filtering or flattening and colleagues (and my future self) get frustrated. I've seen the same thing with overly fancy iterator chaining in Rust.

There's some temptation to think that terse==readable, but in practice this rarely extends beyond the simplest cases.

View on HN

I didn't yet get around to writing Go in any significant capacity (it's not in an interesting spot for me) but I've had to read some and to me it seems like about half of all Go code does approximately nothing. It seems really weird to me that Go doesn't have a Result/Optional type (or sum types in general) and instead prefers multiple return values instead, and consequentially does not have error-handling operators but requires if err != nil repeated approximately 9000 times per file.

This seems like a real sticking point for a lot of people. Personally, I don't seem to think about code volume in units of "lines" but rather in units of "complexity" and "locality". I would like to see Result and Optional types, but in practice everyone understands that (nil, err) is the same as Result::Err and that (*T, nil) is the same as Result::Ok. Of course, you miss out on monadic properties, but after extensively using the language, that's a feature 99% of the time. I would say give it a shot; I was skeptical at first, but this is surprisingly not an issue IMO.

The real issues (IMO) with Go error handling are the clunky `errors.Is()` and `errors.As()` functions for catching specific error values and types respectively as well as annotating errors to get the requisite context (this may already have a solution which just hasn't yet become idiomatic across the ecosystem). In the meanwhile, I just wrap errors with extra context which isn't super satisfying but largely does the trick, e.g., `return fmt.Errorf("writing to database: %w", err)`. Rust seems to have similar problems with respect to different patterns and libraries for error handling, despite having a standard Result type.

One of the issues I had with Go was that even though functions can return pseudo-tuples (multiple return values), there are no tuples anywhere else in the language. So you can't chain functions which return (T, err), easily create a slice of their return values, feed their output to a channel, etc. Just made handling operations on slices so tedious

I didn't claim that terse is always more readable. It was in the example I gave, and practically every golang program could be written in a more terse, more readable, and less error prone way in Python/Java/C#/etc.

I understand that you didn’t claim this explicitly, but it’s a common misconception so I addressed it anyway. While I have no doubt that a given Go program could be written more tersely in Python, Java, or C# I’ve written and operated enough programs in those languages to know that the results are rarely if ever more readable or less error-prone. I think Go’s preferences for simplicity over cleverness and explicitness over terseness are significant factors in these readability and quality disparities. Newline characters aren’t where your bugs are coming from.

> There's some temptation to think that terse==readable, but in practice this rarely extends beyond the simplest cases

A quick glance at any array language (APL, J, K, Q, etc.) confirms this. ;)

Reply on news.ycombinator.com