Go 1.18 • Hacker News Board

Re: Go 1.18

#411

Post by manigandham » Wed, Mar 16, 2022, 5:26 AM UTC

yashap wrote: post #399

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

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?

Re: Go 1.18

#412

Post by _wldu » Wed, Mar 16, 2022, 5:37 AM UTC

yashap wrote: post #399

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

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…

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

Re: Go 1.18

#413

Post by rob74 » Wed, Mar 16, 2022, 5:43 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?

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.

Re: Go 1.18

#414

Post by pipe_connector » Wed, Mar 16, 2022, 5:45 AM 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…

I legitimately cannot spot the bug. Can you write out the equivalent Ruby code in Go pre-generics? I really did try but I honestly cannot understand what your Ruby code is supposed to do. I don't know what select and take are supposed to do, and I can guess at reduce but the symbols in the method are utterly arcane to me. Does Take grab exactly 20 items or does it do something like nums[:21]? Depending on how Take is implemented it could be an off-by-one error in your loop? Usually in this case I'd check for equality instead; that's the only thing that looks off to me in your Go code.

In my opinion the Go code is dead simple and unambiguous with no nuance hidden away in methods whose exact semantics I certainly don't have memorized. I'd have to look at 3 different function signatures to figure out what those Ruby methods do every single time I was reviewing code like this.

Re: Go 1.18

#415

Post by rob74 » Wed, Mar 16, 2022, 5:46 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?

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.

Re: Go 1.18

#416

Post by yashap » Wed, Mar 16, 2022, 5:47 AM UTC

_wldu wrote: post #412

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…

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

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.

Re: Go 1.18

#417

Post by phplovesong » Wed, Mar 16, 2022, 5:54 AM UTC

andrewf wrote: post #14

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…

I work at a Go shop that was a Python + RoR shop when I joined. I don't dispute Go's benefits at our scale. As a matter of personal preference, I don't enjoy Go. Go is Blub ( http://www.paulgraham.com/avg.html ). I think the industry is in a place where Blub makes sense! Lots of VC money is floating around, and schools are training a lot of people to hire with that money. Commercially relevant ideas most often succee…

Disclaimer: I don't use Go professionally

When compared to say, Ocaml Go definitely lacks some of the niceties of a type system (even now with generics). With ocaml i use recursion in almost every case i need to reduce / map something. Pattern matching + type constructors are VERY powerful and produces very safe code.

That said, i really like Go as a language. It lacks many higher level abstractions, and the coding style is very procedural. It's boring, and stops you from being to clever. Simply put, i get shit DONE in Go without much thinking. sometimes i work for hours in Ocaml to get a semi "easy" function to work correctly. With Go it's just write and things usually work.

Go has very good concurrency primitives for 95% of use cases. Ad hoc concurrency in Ocaml is still a pain (the new effect system WILL make this better) as you need to pick and choose between Ltw or async and then pray libraries support the one you chose.

For me Ocaml is still a language (that i love) for "being smart about it". And good ocaml code is truly beautiful and safe. Go on the other hand is about getting shit done. I can be productive in Go and then refactor later.

I really like that Go has such a good core that comes with the essentials, so you rarely need higher level dependencies (i would not write a databada driver myself).

Go sits in a spot that's well designed and has the right tools and brings good enough safety to the average app.

Re: Go 1.18

#418

Post by yashap » Wed, Mar 16, 2022, 5:55 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?

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.

Re: Go 1.18

#419

Post by alex_sf » Wed, Mar 16, 2022, 6:12 AM UTC

saurik wrote: post #351

jshen wrote: post #327

Earlier quoted context omitted.

Yes, it’s a trade-off. In an organization with thousands of developers the right trade-off is likely different than an org with 20. What I don’t understand is why people insist on making Go like every other language that already does what that are looking for. You want a language with generics, purely functional blah blah blah, great there are tons of choices, use one of them. Why insist on reducing the diversity in…

This is what policies are for, not entirely new languages: if you don't like generics and don't trust the end developers at your organization to not use them in stupid ways you should maybe (I say "maybe" as this problem just seems so lame of a problem to have: if your army of end developers can't be trusted then you should fire them and hire some real developers) have a way to turn off generics that isn't "use a lan…

Policies don't work. It's why we lean on process in fields where correctness matters, e.g. aviation.

Re: Go 1.18

#420

Post by yashap » Wed, Mar 16, 2022, 6:23 AM UTC

mhio wrote: post #350

kaba0 wrote: post #261

Earlier quoted context omitted.

Scala is pretty close to Go in terms of popularity and I would argue that it has a much bigger ecosystem due to the JVM. It is also pretty much a typed python in terms of ease of use, and the JVM has stellar performance — other than small running scripts, for many kind of workloads Java’s state of the art GC will have better throughput than Go’s.

What metric do you use for popularity? I'm more involved in the systems side so I'm definitely over exposed to Go projects. I would have considered Scala to be at least an order of magnitude less "popular" than Go. Kafka is the only open source project in Scala I can recall running into but there's probably a whole enterprise world I don't see.

For open source projects, it’s very popular in the “big data” world. Kafka, as you mentioned, but also Spark, Flink, Summingbird, Scalding, etc.

And yeah, it’s a pretty popular backend language at some large companies. Twitter, LinkedIn, Netflix, the Guardian, Starbucks, AirBnB, Coursera, AT&T, etc. all make significant use of Scala.

Go is certainly bigger, but Scala has plenty of adoption too.