Go 1.18

Post by lenkite » Wed, Mar 16, 2022, 9:47 AM UTC

preseinger wrote: post #287

pie_flavor wrote: post #277

I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' as it solves a problem that has resulted in an absolutely ludicrous amount of weird boilerplate garbage code. You're not trading off generic code vs non-generic code. Problems are generic. For solving generic problems , you're trading off the generic code that best expresses them, for codegen, dynamic downcasting,…

Problems are not generic. "I need a N-ary binary tree over arbitrary comparable types" is not a problem. Problems are expressed in terms of domain concepts that are unique to the problem space, the organization, the business need. Some _implementation details_ or maybe patterns that can be used to solve those problems may be generic. That's separate.

Post by morelisp » Wed, Mar 16, 2022, 9:52 AM UTC

randomswede wrote: post #453

thegeekpirate wrote: post #434

Earlier quoted context omitted.

> 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.

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.

Post by thegeekpirate » Wed, Mar 16, 2022, 9:58 AM UTC

randomswede wrote: post #453

thegeekpirate wrote: post #434

Earlier quoted context omitted.

> 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.

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.

    if _, exists := something[item]; exists { ... }

Post by lifty » Wed, Mar 16, 2022, 10:03 AM UTC

zozbot234 wrote: post #437

yashap wrote: post #418

Earlier quoted context omitted.

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…

> 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 complexi…

Post by torginus » Wed, Mar 16, 2022, 10:04 AM UTC

manigandham wrote: post #411

yashap wrote: post #399

Earlier quoted context omitted.

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 - Mona…

Why are new data structures worrying?