38 ms·

I think that some of the concerns around generics, (like mine) are based on the over-use of generics. But, I am very happy for the addition of generics as they'

• hobofan 5y ago
  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
• tomp 5y ago
  Why is this a concern with generics, but not with e.g. if statements? They too can be over-used (i.e. over-nested)
  • laumars 5y ago
    Your example here is a little on the absurd side don’t you think? While the lack of generics in a language can be annoying for some people it’s not a showstopper for most use cases. Whereas removing conditionals would make it a non-starter for most people. And the fact that Go does now have generics should demonstrate that the language is trying to be pragmatic rather than just trolling the community. It’s worth noting that Go vetting tools do capture a few instances of “misusing” ‘if’ statements so taking your comment sincerely (which is more than it deserves imo), your worst case scenario is already covered.
    • cannabis_sam 5y ago
      > Your example here is a little on the absurd side don’t you think? While the lack of generics in a language can be annoying for some people it’s not a showstopper for most use cases. Whereas removing conditionals would make it a non-starter for most people. I don’t want if-statements at all in my code, if-expressions at the most, but they are strictly worse than pattern matching anyways.
      • laumars 5y ago
        Congratulations on being the exception that demonstrates why I said “most people”. The great thing about our current era is that you have more choices in languages and compilers than you have hours in your life to learn them all. So you can be as fussy as you want and there will still be an ecosystem out there for you. There wasn’t nearly this many choices when I started out in IT. And most of the options that weren’t even free.
        • erik_seaberg 5y ago
          My company has choices; I don’t. I joined an explicitly Java-centric team (even Scala for some use cases) yet Go is getting harder to avoid.