Go 1.18 • Hacker News Board

Re: Go 1.18

#401

Post by randomdata » Wed, Mar 16, 2022, 4:30 AM UTC

throwaway894345 wrote: post #332

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 wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' Who says this? There have been a lot of weird arguments surrounding Go and generics over the last decade, but I’ve never heard anything like this.

I don't know who is saying it, but you can certainly find GitHub repositories of people who have been playing around with generics creating it. Presumably it is people being silly or playing around to see how far they can push the feature under experimental conditions, but developers have also been known to unfathomable things in real code, so I can kind of understand the sentiment. Channels lead to a lot of weird and garbage code when they were new and shiny, when developers felt they should use them for the sake of using them, so the idea isn't unprecedented either.

Re: Go 1.18

#402

Post by jshen » Wed, Mar 16, 2022, 4:33 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…

I’m not talking about generics specifically. I’ve been coding for decades. Go is by far the easiest language I’ve used when it comes to jumping into an arbitrary code base and making sense of it.

Again I ask, why insist that go become the same as all the other languages when you can just use one of those? Why demand less diversity?

Re: Go 1.18

#403

Post by oxplot » Wed, Mar 16, 2022, 4:34 AM UTC

int_19h wrote: post #367

oxplot wrote: post #138

When you hear most critics of Go (or any language for that matter), they talk as if Go is merely an alternative syntax for their favorite language. Of course they're bothered by lack of a missing features and unfamiliar ways. As tired of an analogy as it may be, programming languages are like natural languages. Trying to learn Japanese by translating sentences, idioms and proverbs from English word for word will only…

Most critics of Go are well aware of its history and purported design goals. The problem is that the set of features that actually are in Go (like channels) versus those that weren't (like generics) or still aren't (like enums) doesn't really make sense when taking those design goals at face value. For example, generics. Like you say, the original claim was that they didn't want to do them because they thought that m…

> What, exactly, was gained here to justify the productivity lost while waiting?

The goal isn't to wait long enough to come up with something novel. That's what research projects are for, and Go is on the exact opposite of the spectrum. If after deliberation, it turns out that a mostly similar solution is the way to go, then that's doing it "right".

Also, the lost productivity that keeps getting mentioned is overblown. The minority who actually need it (a subset of those who ask for it) are, well, a minority but a loud one. I have developed in Go for 8 years. I only ever reached for generics twice and in both cases, copy pasting the implementation in different types added a insignificant effort.

> Go is a very boring language in a sense that there's very little new there

You hit it on the nail! It's boring. That's what you need when you're targeting large distributed teams and want your code base to survive decades and still be readable and navigatable by pros and amateurs alike. You don't want clever or smart. You don't want cutting edge and novel for novelty's sake. You don't want magic. You don't want to have to keep the context of 20 files in your head to understand one line of code. You don't want a syntax that can be interpreted in 10 different ways in different contexts, ... . You want the sweet spot between simple and practical.

Back to:

> Most critics of Go are well aware of its history and purported design goals.

Your comment about Go being boring and its lack of novel features, is clearly demonstrating that you've either missed or misunderstood the design goals. And many similar comments on other parts of the language from others I've interacted with is what I was basing my parent reply on.

Re: Go 1.18

#404

Post by rtpg » Wed, Mar 16, 2022, 4:39 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.

I mean Go has map right?

"I need a priority queue for X" isn't generic, and "I need a priority queue for Y" isn't generic either. But well if you're doing it a lot, would be nice to not just reproduce the same bugs over and over again, yeah?

Everyone's worried about Go turning into Java and I can't speak too much to the utility (I have written maybe 50 pages of go in my life) but anyone who uses Python's standard lib can point you to 10 different things that are nice to have bug-free versions of and that "just work" thanks to Python's "generics".

Re: Go 1.18

#405

Post by svnpenn » Wed, Mar 16, 2022, 4:39 AM UTC

frenchie4111 wrote: post #139

In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional

Why can't you just do something like this:

    func hello() (string, bool)

Re: Go 1.18

#406

Post by alex_sf » Wed, Mar 16, 2022, 4:45 AM UTC

alophawen wrote: post #371

metadat wrote: post #317

Earlier quoted context omitted.

Goroutines and channels seem comparatively simple compared to the representational symbolic changes involved with generics, which make the code look and read more like Greek. The beauty of Go is (was) largely in its simplicity and python-esque (or maybe better than python) readability. With generics, reading and reasoning about code becomes [even] more challenging. Personally for me, at this juncture I'm finding that…

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.

Re: Go 1.18

#407

Post by alex_sf » Wed, Mar 16, 2022, 4:46 AM UTC

munificent wrote: post #290

dimgl wrote: post #284

Earlier quoted context omitted.

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…

There's a lot of developers that misuse/shouldn't use any powerful feature. If the solution is to give them a nerfed language, then you also nerf it for the users that would use the feature well in productive, useful ways.

That was one of the goals and virtues of Go imo; the language was nerfed. It made the hard things easy, and prevented the really hard things from being implemented in silly ways.

Re: Go 1.18

#408

Post by svnpenn » Wed, Mar 16, 2022, 4:47 AM UTC

titzer wrote: post #238

cube2222 wrote: post #92

Great to see this! Generics will drastically improve datastructure libraries. That said, for people worrying about overcomplication, fortunately methods can't have type parameters. That means ergonomic monads are not possible to implement, and we'll most probably not see the whole functional story play out in Go.

> fortunately methods can't have type parameters. This is quite tricky to implement properly if the compiler doesn't do some form of specialization. (Basically, you need a different vtable entry for each instantiation of a generic method, or you need a runtime lookup to find it). But given that the Go compiler is doing complete specialization, I'm surprised they left this out. Generic methods (on classes) are the way…

> It's a limitation that will eventually catch up with you.

Go worked fine without it for 10 years...

Re: Go 1.18

#409

Post by bobbylarrybobby » Wed, Mar 16, 2022, 5:12 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 would anyone be worried about being able to write code that more closely matches the problem domain?

Re: Go 1.18

#410

Post by lanstin » Wed, Mar 16, 2022, 5:19 AM UTC

avl999 wrote: post #213

_0w8t wrote: post #67

For me the most puzzling aspect of Go is channels. Ada tried CSP (Concurrent Sequential Processes that Go channels are based on) in eighties and people quickly realized that it lead to bad performance and was unsuitable for a lot of useful cases. So Ada got standard mutexes and signals. So why CSP which does not allow to implement priority delivery or multicasting and makes cancelling much harder compared with normal…

Avoid channels except for straight forward, producer-consumer workflows. Use mutexes and other traditional concurrency primitives for other stuff. Channels are a huge shotgun with caveats.

The thing about channels is, while they might be slow for tight inner loop type compute code, it lets you scale across all the cores very linearly. And, given a channel to flow the work thru, you can manage the number of workers at each stage however you like - growing with more load, dropping work with more load, back pressure with more load. All concisely and explicitly. And a lot of network server things are classic producer/consumer things, so it’s great to have a solution for that where you get concurrency without any thread worries.