5 ms·

It's not surprising that the code base grew when reimplemented in golang. It would have probably been even shorter had it been rewritten in Python itself. Just

by azth 5y ago

It's not surprising that the code base grew when reimplemented in golang. It would have probably been even shorter had it been rewritten in Python itself. Just the other day, I was able to condense over 15 lines of golang code into 3 lines (could also have been 2 lines) in a Python-like syntax, both reducing code length, and substantially increasing readability as it would make the underlying logic clearly stand out instead of having several loop and map constructs.

throwaway894345 5y ago
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.
- formerly_proven 5y ago
  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.
  - throwaway894345 5y ago
    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.
  - Polygator 5y ago
    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
- azth 5y ago
  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.
  - throwaway894345 5y ago
    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.
- nemo1618 5y ago
  > 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. ;)

by azth 5y ago

throwaway894345 5y ago

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.

formerly_proven 5y ago
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.
- throwaway894345 5y ago
  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.
- Polygator 5y ago
  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
azth 5y ago
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.
- throwaway894345 5y ago
  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.
nemo1618 5y ago
> 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. ;)