7 ms·

I’m a big fan of Go adding generics, but I can see some of what people are worried about. I don’t think it’s “business logic that would benefit from being made

by yashap 5y ago

I’m a big fan of Go adding generics, but I can see some of what people are worried about. I don’t think it’s “business logic that would benefit from being made generic”, it’s that generics allow people to write new data structures that aren’t currently reasonable to write in Go. For example: - Sets - Trees/graphs - Stacks/queues - List-like data structures with different performance characteristics than slices - Monadic data structures you find in functional languages, like Option (for dealing with the lack of a value), Either (one of two possible values), Future (basically either a success or an error, computed asynchronously), etc. I’m sure we’ll see popular libraries providing all of the above, and more. Generics will make for a wider variety of programming styles in Go, which has downsides as well as upsides. Go will likely get a bit more functional/declarative/high-level, a bit less imperative/procedural/low-level. It’s not about to become Haskell or Scala, but maybe a bit more like TypeScript or statically typed Python, a bit less like C.

bobbylarrybobby 5y ago
Why would anyone be worried about being able to write code that more closely matches the problem domain?
- rob74 5y ago
  Spending lots of effort designing your type system to match your problem domain (or rather, what you think is your problem domain) is a pitfall which was made less likely by "classic" Go because the available types were very straightforward. Which also made it easier to refactor your code when you inevitably realized your initial approach didn't match the problem domain that well after all (or the problem domain changed, as it tends to do when you maintain an application over several years). And I totally understand that people are worried having generics will change this.
- baby 5y ago
  Readability, complexity, security
- jeltz 5y ago
  Because generics rarely help with that. I love generics for writing libraries and for giving me libraries which are easy to use but my business logic is almost never generic. Most problem domains I have worked in have not been very generic.
manigandham 5y ago
Why are new data structures worrying?
- rob74 5y ago
  Because they add cognitive load, make it harder to read a piece of code and understand what it is doing (and therefore can hide errors) etc. etc.
- yashap 5y ago
  The downside is they’ll make Go code less uniform. Do you represent nullability with a nil-able pointer, or an option monad? To transform a list, do you loop over a slice, or map/flatMap/filter over a more functional data structure? etc. Pre-generics, Go has been a very limited language. On the downside it’s verbose and error-prone, on the upside it’s very uniform. I think generics will make it less verbose and error-prone, but also less uniform - stylistic differences from programmer to programmer will be greater, similar to other high level languages.
  - zozbot234 5y ago
    > Pre-generics, Go has been a very limited language. On the downside it’s verbose and error-prone, on the upside it’s very uniform. Except that this kind of uniformity inherently tends to disappear in larger projects, to be replaced by increased complexity. Java was also designed to be a "simple" language, one trivially understandable by hordes of low-skilled code monkeys, and yet look at the added layers of complexity in many Java enterprise frameworks. More full-featured languages, when properly designed (especially, avoiding the feeping creaturitis of something like Scala), make it easier not harder to manage inherent complexity at a larger and larger scale of development. But Go is now basically stuck with its constrained feature set, and Go developers cannot easily avail themselves of these tools. This is why so many devs criticize this particular design goal; it's pretty much incoherent.
    - baby 5y ago
      I’ve audited a bunch of complex codebases in Golang that were very readable. Surprisingly readable actually
_wldu 5y ago
Go has maps already. A set is just a map where the key and value are the same thing.
- yashap 5y ago
  Sets tend to have methods like difference, union and intersection - with a map[T]bool, if you want to find the difference, union or intersection of 2 sets, you have to do all of that with much more verbose (and error prone) loops. Also, the type being a set carries a semantic meaning, with a map[T]bool it’s not obvious from the type alone that we only care about the keys, not the values.
  - thegeekpirate 5y ago
    > with a map[T]bool This takes up unnecessary space—use map[T]struct{} instead, which also explains to anyone reading the code that the value isn't used.
    - randomswede 5y ago
      There is a slight difference between the two. With a map[†]bool, you can do something like: if myset[thing] { ... } With a map[T]struct(), you end up with: if _, ok := myset[thing]; ok { ... } Sometimes, the saving in space is TOTALLY worth the extra verbosity. Sometimes, the slight clarity from "non-existent keys return the zero value" wins.
      - morelisp 5y ago
        Well, now there's no excuse for not having `myset.Contains(thing)` (though there really wasn't before either) which is even clearer.
      - thegeekpirate 5y ago
        You've also opened yourself up to bugs by allowing the map values to be "false". Using a "set's" value in an if statement doesn't make sense either, compared to if _, exists := something[item]; exists { ... } which is explicit regarding what's actually going on. As Rob said, "Clear is better than clever." https://www.youtube.com/watch?v=PAAkCSZUG1c&t=875s https://www.youtube.com/watch?v=PAAkCSZUG1c&t=875s I also don't want to be hunting down whoever creates a map[T]bool and doesn't leave a comment explaining it's a set ;) Hopefully we won't have to worry about it for much longer regardless, since I imagine we'll be using proper sets (with methods) some point in the near future.

by yashap 5y ago

bobbylarrybobby 5y ago

Why would anyone be worried about being able to write code that more closely matches the problem domain?

rob74 5y ago
Spending lots of effort designing your type system to match your problem domain (or rather, what you think is your problem domain) is a pitfall which was made less likely by "classic" Go because the available types were very straightforward. Which also made it easier to refactor your code when you inevitably realized your initial approach didn't match the problem domain that well after all (or the problem domain changed, as it tends to do when you maintain an application over several years). And I totally understand that people are worried having generics will change this.
baby 5y ago
Readability, complexity, security
jeltz 5y ago
Because generics rarely help with that. I love generics for writing libraries and for giving me libraries which are easy to use but my business logic is almost never generic. Most problem domains I have worked in have not been very generic.

manigandham 5y ago

Why are new data structures worrying?

rob74 5y ago
Because they add cognitive load, make it harder to read a piece of code and understand what it is doing (and therefore can hide errors) etc. etc.
yashap 5y ago
The downside is they’ll make Go code less uniform. Do you represent nullability with a nil-able pointer, or an option monad? To transform a list, do you loop over a slice, or map/flatMap/filter over a more functional data structure? etc. Pre-generics, Go has been a very limited language. On the downside it’s verbose and error-prone, on the upside it’s very uniform. I think generics will make it less verbose and error-prone, but also less uniform - stylistic differences from programmer to programmer will be greater, similar to other high level languages.
- zozbot234 5y ago
  > Pre-generics, Go has been a very limited language. On the downside it’s verbose and error-prone, on the upside it’s very uniform. Except that this kind of uniformity inherently tends to disappear in larger projects, to be replaced by increased complexity. Java was also designed to be a "simple" language, one trivially understandable by hordes of low-skilled code monkeys, and yet look at the added layers of complexity in many Java enterprise frameworks. More full-featured languages, when properly designed (especially, avoiding the feeping creaturitis of something like Scala), make it easier not harder to manage inherent complexity at a larger and larger scale of development. But Go is now basically stuck with its constrained feature set, and Go developers cannot easily avail themselves of these tools. This is why so many devs criticize this particular design goal; it's pretty much incoherent.
  - baby 5y ago
    I’ve audited a bunch of complex codebases in Golang that were very readable. Surprisingly readable actually

_wldu 5y ago

Go has maps already. A set is just a map where the key and value are the same thing.

yashap 5y ago
Sets tend to have methods like difference, union and intersection - with a map[T]bool, if you want to find the difference, union or intersection of 2 sets, you have to do all of that with much more verbose (and error prone) loops. Also, the type being a set carries a semantic meaning, with a map[T]bool it’s not obvious from the type alone that we only care about the keys, not the values.
- thegeekpirate 5y ago
  > with a map[T]bool This takes up unnecessary space—use map[T]struct{} instead, which also explains to anyone reading the code that the value isn't used.
  - randomswede 5y ago
    There is a slight difference between the two. With a map[†]bool, you can do something like: if myset[thing] { ... } With a map[T]struct(), you end up with: if _, ok := myset[thing]; ok { ... } Sometimes, the saving in space is TOTALLY worth the extra verbosity. Sometimes, the slight clarity from "non-existent keys return the zero value" wins.
    - morelisp 5y ago
      Well, now there's no excuse for not having `myset.Contains(thing)` (though there really wasn't before either) which is even clearer.
    - thegeekpirate 5y ago
      You've also opened yourself up to bugs by allowing the map values to be "false". Using a "set's" value in an if statement doesn't make sense either, compared to if _, exists := something[item]; exists { ... } which is explicit regarding what's actually going on. As Rob said, "Clear is better than clever." https://www.youtube.com/watch?v=PAAkCSZUG1c&t=875s https://www.youtube.com/watch?v=PAAkCSZUG1c&t=875s I also don't want to be hunting down whoever creates a map[T]bool and doesn't leave a comment explaining it's a set ;) Hopefully we won't have to worry about it for much longer regardless, since I imagine we'll be using proper sets (with methods) some point in the near future.