5 ms·

Not giving the programmer a choice and forcing them to be pragmatic was one of the main selling points of Go. Allowing generics at all will likely make them see

Not giving the programmer a choice and forcing them to be pragmatic was one of the main selling points of Go. Allowing generics at all will likely make them seep into he ecosystem over time and destroy part of that value proposition.

OtomotO 5y ago
Being pragmatic could also mean using generics when appropriate. Not having generics isn't a pragmatic choice per se
- deepsun 5y ago
  Exactly the same can be said about checked exceptions.
  - TheMonarchist 5y ago
    C++ used to have opt-in checked exceptions ("dynamic exception specification"), that were deprecated in 2011 and removed in 2017. That the once standard feature was removed from C++ speaks a lot.
vgatherps 5y ago
The claim that Go 'forces people to be pragmatic' applies a pretty strong value judgement to the way things Go does. You could say "Go forces people do things the way Go wants and this way is wonderful for many use cases" (I don't disagree), but whether that way is pragmatic or not depends on the use case.
- threeseed 5y ago
  There is nothing pragmatic about Go's approach to error handling. It's the equivalent of putting your head in the sand and pretending nothing else in the world exists.
  - politician 5y ago
    Programming is much more about understanding guarantees and curating the error path than it is about pulling a ticket from Jira and cranking out a happy path as agilely as you can. Error handling in other languages is like confetti. “Pop! Surprise!” A disorganized game of “52 pickup” using an under designed grab bag of control structures. No thanks.
    - rsj_hn 5y ago
      Lack of adequate control structures, or for that matter, programming language support, is almost never the reason why code has inadequate error handling. The main reason is that developers often leave error handling as an afterthought because it distracts them from thinking about the main flow, and it's hard to program when you are constantly distracted. That's why you have overbroad exception handling and the consequent improper handling. The problem is with the brain, not with the programming language.
      - preseinger 5y ago
        > developers often leave error handling as an afterthought because it distracts them from thinking about the main flow Go asserts that "error handling" and "main flow" (a.k.a. "happy path") code paths are equivalent, and that you can't ignore the bad stuff as you program against the good stuff. Error handling _cannot be_ an afterthought -- this is the path to fragile, even broken, code. If a programmer can't adapt to this model, then they're gonna have a bad time with Go, because with Go it's non-optional!
        plorkyeran 5y ago
        No, it really doesn't do that. Result types which force you to check for an error to get the non-error return value from a function, or Swift `try` which doesn't even let you call a function which may fail without writing some sort of error handling do that. Go leaves it up to the programmer to remember to check for errors, and lets you silently discard the error result.

OtomotO 5y ago

Being pragmatic could also mean using generics when appropriate. Not having generics isn't a pragmatic choice per se

deepsun 5y ago
Exactly the same can be said about checked exceptions.
- TheMonarchist 5y ago
  C++ used to have opt-in checked exceptions ("dynamic exception specification"), that were deprecated in 2011 and removed in 2017. That the once standard feature was removed from C++ speaks a lot.

vgatherps 5y ago

The claim that Go 'forces people to be pragmatic' applies a pretty strong value judgement to the way things Go does. You could say "Go forces people do things the way Go wants and this way is wonderful for many use cases" (I don't disagree), but whether that way is pragmatic or not depends on the use case.

threeseed 5y ago
There is nothing pragmatic about Go's approach to error handling. It's the equivalent of putting your head in the sand and pretending nothing else in the world exists.
- politician 5y ago
  Programming is much more about understanding guarantees and curating the error path than it is about pulling a ticket from Jira and cranking out a happy path as agilely as you can. Error handling in other languages is like confetti. “Pop! Surprise!” A disorganized game of “52 pickup” using an under designed grab bag of control structures. No thanks.
  - rsj_hn 5y ago
    Lack of adequate control structures, or for that matter, programming language support, is almost never the reason why code has inadequate error handling. The main reason is that developers often leave error handling as an afterthought because it distracts them from thinking about the main flow, and it's hard to program when you are constantly distracted. That's why you have overbroad exception handling and the consequent improper handling. The problem is with the brain, not with the programming language.
    - preseinger 5y ago
      > developers often leave error handling as an afterthought because it distracts them from thinking about the main flow Go asserts that "error handling" and "main flow" (a.k.a. "happy path") code paths are equivalent, and that you can't ignore the bad stuff as you program against the good stuff. Error handling _cannot be_ an afterthought -- this is the path to fragile, even broken, code. If a programmer can't adapt to this model, then they're gonna have a bad time with Go, because with Go it's non-optional!
      - plorkyeran 5y ago
        No, it really doesn't do that. Result types which force you to check for an error to get the non-error return value from a function, or Swift `try` which doesn't even let you call a function which may fail without writing some sort of error handling do that. Go leaves it up to the programmer to remember to check for errors, and lets you silently discard the error result.