Go 1.18

Post by [deleted] » Wed, Mar 16, 2022, 8:48 AM UTC

dimgl wrote: post #284

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

Disclaimer: I'm extremely happy that generics are coming to Go. > I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' It's pretty simple: there's a lot of developers that misuse/shouldn't use generics. Here's an article I found just casually browsing on Google that shows why this can turn out to be such a huge problem. https://itnext.io/golang-1-18-generics-the-goo…

Post by randomswede » Wed, Mar 16, 2022, 8:50 AM UTC

thegeekpirate wrote: post #434

yashap wrote: post #416

Earlier quoted context omitted.

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.

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

Post by baby » Wed, Mar 16, 2022, 8:56 AM UTC

bobbylarrybobby wrote: post #409

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 would anyone be worried about being able to write code that more closely matches the problem domain?

Post by baby » Wed, Mar 16, 2022, 8:59 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 baby » Wed, Mar 16, 2022, 9:03 AM UTC

alex_sf wrote: post #406

alophawen wrote: post #371

Earlier quoted context omitted.

I spent 4 months in '21 rewriting a golang backend to properly use channels for concurrency. The previous developers did misuse it and left a steaming pile for me to find. However contracting pays well, so I don't care. You might want to reflect on your reasons for jumping ship because your tooling gained a new feature. Sound's rather irrational to me.

It's less that it gained a new feature, and more (the fear at least) that it made a change for the worse. Avoiding updating to a new version of OSX that stabs you in the face is a reasonable thing to do, despite it being a new feature.