6 ms·

The cumbersome style seems to have become a strong part of the culture, almost a masochism about the limited features of the language. I find this ironic becaus

by jolux 5y ago

The cumbersome style seems to have become a strong part of the culture, almost a masochism about the limited features of the language. I find this ironic because I believe Go was intended to be highly pragmatic originally but it seems to have evolved an almost Scheme-like dogmatism about language complexity.

Serow225 5y ago
Thank you for naming this. I've always struggled with how to convey this to people.
skywhopper 5y ago
Do you have specific examples you’re thinking of? Calling it masochism is weirdly insulting. Adding complexity is a one-way street. Languages live for decades. There’s no reason to rush adding features in a half-baked way, and the tradeoffs in terms of compiler complexity are very real.
- stouset 5y ago
  Virtually every large go program I've read has asymptotically reached 50%+ of its code being if res, err := fn(...); err != nil { fmt.Errorf("Look ma, I'm a human exception handler: ", err) } This is held up as a positive thing, because handling errors is explicit and good. Somehow, the Rust equivalent of `?` is implicit and bad, despite desugaring to almost literally the exact same thing and being actually impossible to forget or overlook due to the return type of the function enforcing a Result. In the same breath, devs will assert that the language is "low boilerplate" (despite 50%+ LOC being just one type of boilerplate) because Error Handling is Important. Which seemingly ignores that the important part of error handling is actually ensuring that errors are handled and not the mechanistic act of self-flagellation by wrapping every line of code in nearly-identical error handling ceremony. Which is unfortunate because golang doesn't do so great a job with the first part. It's surprisingly easy to actually forget to do something with the error while carrying on with a return value whose semantics are undefined (unlike Rust's Result, where you can have an error or a value and not both).
  - eweise 5y ago
    I used to hardly think about exception handling on the jvm, mostly let them bubble up and be centrally handled except in special cases. Now I'm always worried that I'll forgot to manually handle the error in Go. Can't tell you how many times I've gotten panics as well, from nil objects.
  - throwaway894345 5y ago
    I use Go a lot and I really like Rust, so maybe I can add some context. Error handling boilerplate isn’t a big deal. Lines of code aren’t a big deal. That’s not where your bugs are coming from and you aren’t bottlenecked on your typing speed. It’s not a real problem, but rather a dogmatic pursuit of terseness for its own sake. Rust is an expression-oriented language—it needs something like ? because without it we would have gratuitous nested braces marching ever-rightward and that actually is laborious to keep track of (deeply nested match expressions). Go could drop some error handling boilerplate with an ? operator, but it wouldn’t benefit as much from it as Rust did.
    - closeparen 5y ago
      Lines of code are a very big deal in an organizational context that cares about test coverage. Since all the error handling ceremony is written by hand, so too must a corresponding test case for each instance of the error-handling ceremony be written by hand. Typing out test suites for functions that compose several other error-returning functions is bureaucratic drudgery.
      - lawl 5y ago
        I'll bite. Why not ditch the "% test coverage" metric then, since as you just elaborated, it's not a good metric. I would prefer my language wasn't designed around corporate bureaucracy personally.
        closeparen 5y ago
        I don't think the coverage metric is necessarily wrong to highlight error return branches: they are program logic you typed, and might have mistyped. I certainly have mistyped them. Checked the wrong error value, or returned a different error from the one I checked. You get to skip tests for default exception handling behavior in e.g. Java because you know the language is going to do; there's no opportunity for human error. It is possible to have company policies against abstraction and cleverness when working in more expressive languages, and this would achieve almost the same intent as Go, it's just that actually using Go is more convenient. The language is corporate bureaucracy. The whole point is what's not there. What can't go off in a weird directions on a per-project basis. What junior engineers in a high-turnover environment can't screw up. It's not by accident that the native toolchain will give you a test coverage report with untested error return branches in red. Google is just happy to pay people for that drudgery, I guess.
- jolux 5y ago
  I don’t think masochism is inherently negative and I did not mean to insult. For that I apologize. I was trying to characterize in a humorous fashion a difference between what I perceive to be the stated aims of the language and the experience of actually writing it. It was also an oblique reference to this talk which is one of my favorites: https://youtu.be/mZyvIHYn2zk https://youtu.be/mZyvIHYn2zk

by jolux 5y ago

Serow225 5y ago

Thank you for naming this. I've always struggled with how to convey this to people.

skywhopper 5y ago

Do you have specific examples you’re thinking of? Calling it masochism is weirdly insulting. Adding complexity is a one-way street. Languages live for decades. There’s no reason to rush adding features in a half-baked way, and the tradeoffs in terms of compiler complexity are very real.

stouset 5y ago
Virtually every large go program I've read has asymptotically reached 50%+ of its code being if res, err := fn(...); err != nil { fmt.Errorf("Look ma, I'm a human exception handler: ", err) } This is held up as a positive thing, because handling errors is explicit and good. Somehow, the Rust equivalent of `?` is implicit and bad, despite desugaring to almost literally the exact same thing and being actually impossible to forget or overlook due to the return type of the function enforcing a Result. In the same breath, devs will assert that the language is "low boilerplate" (despite 50%+ LOC being just one type of boilerplate) because Error Handling is Important. Which seemingly ignores that the important part of error handling is actually ensuring that errors are handled and not the mechanistic act of self-flagellation by wrapping every line of code in nearly-identical error handling ceremony. Which is unfortunate because golang doesn't do so great a job with the first part. It's surprisingly easy to actually forget to do something with the error while carrying on with a return value whose semantics are undefined (unlike Rust's Result, where you can have an error or a value and not both).
- eweise 5y ago
  I used to hardly think about exception handling on the jvm, mostly let them bubble up and be centrally handled except in special cases. Now I'm always worried that I'll forgot to manually handle the error in Go. Can't tell you how many times I've gotten panics as well, from nil objects.
- throwaway894345 5y ago
  I use Go a lot and I really like Rust, so maybe I can add some context. Error handling boilerplate isn’t a big deal. Lines of code aren’t a big deal. That’s not where your bugs are coming from and you aren’t bottlenecked on your typing speed. It’s not a real problem, but rather a dogmatic pursuit of terseness for its own sake. Rust is an expression-oriented language—it needs something like ? because without it we would have gratuitous nested braces marching ever-rightward and that actually is laborious to keep track of (deeply nested match expressions). Go could drop some error handling boilerplate with an ? operator, but it wouldn’t benefit as much from it as Rust did.
  - closeparen 5y ago
    Lines of code are a very big deal in an organizational context that cares about test coverage. Since all the error handling ceremony is written by hand, so too must a corresponding test case for each instance of the error-handling ceremony be written by hand. Typing out test suites for functions that compose several other error-returning functions is bureaucratic drudgery.
    - lawl 5y ago
      I'll bite. Why not ditch the "% test coverage" metric then, since as you just elaborated, it's not a good metric. I would prefer my language wasn't designed around corporate bureaucracy personally.
      - closeparen 5y ago
        I don't think the coverage metric is necessarily wrong to highlight error return branches: they are program logic you typed, and might have mistyped. I certainly have mistyped them. Checked the wrong error value, or returned a different error from the one I checked. You get to skip tests for default exception handling behavior in e.g. Java because you know the language is going to do; there's no opportunity for human error. It is possible to have company policies against abstraction and cleverness when working in more expressive languages, and this would achieve almost the same intent as Go, it's just that actually using Go is more convenient. The language is corporate bureaucracy. The whole point is what's not there. What can't go off in a weird directions on a per-project basis. What junior engineers in a high-turnover environment can't screw up. It's not by accident that the native toolchain will give you a test coverage report with untested error return branches in red. Google is just happy to pay people for that drudgery, I guess.
jolux 5y ago
I don’t think masochism is inherently negative and I did not mean to insult. For that I apologize. I was trying to characterize in a humorous fashion a difference between what I perceive to be the stated aims of the language and the experience of actually writing it. It was also an oblique reference to this talk which is one of my favorites: https://youtu.be/mZyvIHYn2zk https://youtu.be/mZyvIHYn2zk