Go 1.18

Post by [deleted] » Tue, Mar 15, 2022, 9:54 PM UTC

throwaway894345 wrote: post #12

philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

> Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I'm a big Go proponent, and I'm pretty "meh" on generics. They'll make some code easier to read and write, but they'll make a lot of code a lot harder to read (because contrary to popular beli…

Post by acchow » Tue, Mar 15, 2022, 9:57 PM UTC

ithkuil wrote: post #239

thiht wrote: post #235

Earlier quoted context omitted.

There’s a « replace » directive in go.mod.

Yeah I know, but it's suboptimal. If you use it your module cannot be "go install" lled, and it doesn't work for libraries

Post by unfunco » Tue, Mar 15, 2022, 10:00 PM UTC

meetups323 wrote: post #244

henvic wrote: post #58

Tip: If you've only heard about generics, make sure to check out about fuzzing (*testing.F)!

Any idea why they have such a low byte budget? testing.Fuzz would be so much more readable. I'll accept test.Fuzz if 9 characters is the limit for any compound identifier. Is this sort of single letter class naming common in the standard library?

Post by cdelsolar » Tue, Mar 15, 2022, 10:05 PM UTC

stouset wrote: post #241

CraigJPerry wrote: post #228

Earlier quoted context omitted.

>> generics reduce complication That goes against the definition of the word complication. To complicate something is to combine and intertwine it with other concerns. To fold them together is to complicate them. To generify a function is to complicate it with the ability to accept multiple types rather than just one. There are totally great use cases for generics but all the cases I’ve seen are in library code not i…

As a general rule, if you're referencing the dictionary definition of a word to make your point, you're just playing semantic games. You know what people also find complicated? Hundreds of lines code being repeated with superficial edits because of golang's lack of ability to abstract higher-level ideas. It's a stupid toy example, but for a very large number of people nums.take(20).select(&:odd).reduce(&:+) is less c…

Post by gvil » Tue, Mar 15, 2022, 10:09 PM UTC

meetups323 wrote: post #244

henvic wrote: post #58

Tip: If you've only heard about generics, make sure to check out about fuzzing (*testing.F)!

Any idea why they have such a low byte budget? testing.Fuzz would be so much more readable. I'll accept test.Fuzz if 9 characters is the limit for any compound identifier. Is this sort of single letter class naming common in the standard library?