3 ms·

It's the nature of golang to be verbose like that. It has very low code density, meaning it takes writing a lot of code to express something that could have bee

It's the nature of golang to be verbose like that. It has very low code density, meaning it takes writing a lot of code to express something that could have been expressed in a much more concise manner in a stronger modeling language like Java or C#.

throwaway894345 5y ago
I'm strongly of the opinion that people make much too big a deal out of line counts and character counts. I'm very doubtful that there will be a significant difference in quality between two equally-complex programs which differ only in that one is more terse.
- erik_seaberg 5y ago
  The line count determines how much code I have to speed-read at 3 AM because prod is down. My issue with boilerplate is that we have lots of tools for generating it but no well-supported way to summarize it back to something human-readable. I should be focusing on a high-level description of the problem, and the compiler should be filling in as much of the solution as it possibly can. My brain is made of meat and will never get any faster, so this is the only way for the profession to progress.
  - throwaway894345 5y ago
    > The line count determines how much code I have to speed-read at 3 AM because prod is down. I disagree, it’s purely a count of newline characters per my original point (e.g., a third of the lines are just `}` or `]`). > My issue with boilerplate is that we have lots of tools for generating it but no well-supported way to summarize it back to something human-readable In my experience, it’s pretty easy to understand `if err != nil { return err }` and the like at a glance. Similarly a for loop that maps a `[]T` to a `[]U`. I also dispute whether a long chain of .map().foldr().etc() is intrinsically more intuitive than a for loop, especially when the code needs to short circuit. Don’t get me wrong, I like using Rust-style iterator combinators in my hobby time, but it’s because they make me feel clever not because they are more readable than Go-style for loops. TL;DR, I agree that our brains aren’t getting faster and that readability is important, I just don’t think newlines or the lackthereof are the measure of readability.
    - gher-shyu3i 5y ago
      > it’s purely a count of newline characters per my original point It's not simply that. Compare in golang: var res int if <some condition> { res = foo() } else { res = bar() } to what other languages offer like let res = if <some condition> { foo() } else { bar() }; The golang version is both more verbose, and more error prone. These things add up. Let alone how it takes dozens of lines of code in golang to implement what essentially is a sequence of map/filter/groupBy. The logic in languages that support the latter immediately stands out, whereas in golang you have to read it line by line to figure out what's going on. What's ironic is that even with the proposal to add some of those to golang, they're still going to be vastly inferior to the implementations we have in Java/C#/Scala/etc. because they don't compose in golang, and are still going to be very awkward to read.
      - throwaway894345 5y ago
        I definitely like the ternary version, but to my original point I think people make too big a deal about it. With respect to map/filter/groupBy, I rarely find that solutions are clearer when expressed as chains of iterator combinators like these rather than a single for loop, especially when you're dealing with multiple collections and dealing with errors (short-circuiting). I'm writing a lot of Rust lately, and I definitely find myself dealing with this a lot in practice.
  - doggodaddo78 5y ago
    The codebase should be as small as possible: least surprise, readability, security, new features, and debugging. The other way for the profession to progress is to eliminate humans (mostly) with self-programming machines (effectively, a technological singularity).

throwaway894345 5y ago

I'm strongly of the opinion that people make much too big a deal out of line counts and character counts. I'm very doubtful that there will be a significant difference in quality between two equally-complex programs which differ only in that one is more terse.

erik_seaberg 5y ago
The line count determines how much code I have to speed-read at 3 AM because prod is down. My issue with boilerplate is that we have lots of tools for generating it but no well-supported way to summarize it back to something human-readable. I should be focusing on a high-level description of the problem, and the compiler should be filling in as much of the solution as it possibly can. My brain is made of meat and will never get any faster, so this is the only way for the profession to progress.
- throwaway894345 5y ago
  > The line count determines how much code I have to speed-read at 3 AM because prod is down. I disagree, it’s purely a count of newline characters per my original point (e.g., a third of the lines are just `}` or `]`). > My issue with boilerplate is that we have lots of tools for generating it but no well-supported way to summarize it back to something human-readable In my experience, it’s pretty easy to understand `if err != nil { return err }` and the like at a glance. Similarly a for loop that maps a `[]T` to a `[]U`. I also dispute whether a long chain of .map().foldr().etc() is intrinsically more intuitive than a for loop, especially when the code needs to short circuit. Don’t get me wrong, I like using Rust-style iterator combinators in my hobby time, but it’s because they make me feel clever not because they are more readable than Go-style for loops. TL;DR, I agree that our brains aren’t getting faster and that readability is important, I just don’t think newlines or the lackthereof are the measure of readability.
  - gher-shyu3i 5y ago
    > it’s purely a count of newline characters per my original point It's not simply that. Compare in golang: var res int if <some condition> { res = foo() } else { res = bar() } to what other languages offer like let res = if <some condition> { foo() } else { bar() }; The golang version is both more verbose, and more error prone. These things add up. Let alone how it takes dozens of lines of code in golang to implement what essentially is a sequence of map/filter/groupBy. The logic in languages that support the latter immediately stands out, whereas in golang you have to read it line by line to figure out what's going on. What's ironic is that even with the proposal to add some of those to golang, they're still going to be vastly inferior to the implementations we have in Java/C#/Scala/etc. because they don't compose in golang, and are still going to be very awkward to read.
    - throwaway894345 5y ago
      I definitely like the ternary version, but to my original point I think people make too big a deal about it. With respect to map/filter/groupBy, I rarely find that solutions are clearer when expressed as chains of iterator combinators like these rather than a single for loop, especially when you're dealing with multiple collections and dealing with errors (short-circuiting). I'm writing a lot of Rust lately, and I definitely find myself dealing with this a lot in practice.
- doggodaddo78 5y ago
  The codebase should be as small as possible: least surprise, readability, security, new features, and debugging. The other way for the profession to progress is to eliminate humans (mostly) with self-programming machines (effectively, a technological singularity).