Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generics enabled by default in Go tip

go-review.googlesource.com

Post reply on HN
Print view View original

121–130 of 378 posts

Re: Generics enabled by default in Go tip

#121

Post by kmm01 »

jshen wrote: post #48
vorpalhex wrote: post #41

Earlier quoted context omitted.

Without generics, I have seen terrible and unreadable golang code. There is no tool that can not be mis-used. Generics are adding a tool to the toolbox. They can be used well or they can be mis-used. I recently wrote a gui app in Golang using Fyne and I really wish I'd had generics for some of the UI handling - instead I ended up having to write some really ugly and not simple code to handle the case. The end result…

Can you give an example of terrible unreadable go code due to a lack of generics? I’ve grown to love go because it’s one of the few languages where I can jump into a new code base and relatively easily understand what is going on.

Because you will already have seen that precise piece of code in a thousand other contexts?

Re: Generics enabled by default in Go tip

#122

Post by dmix »

tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

This is why you have to be a tough leader when you’re the designer of anything. But especially languages which naturally draw an endless barrage of comparisons and tribal opinions.

You see this a lot in web design, everyone thinks they’re an expert at what makes a good website - simply because they are a consumer of them. Even if they only have minimal experience building one IRL.

Re: Generics enabled by default in Go tip

#123

Post by takeda »

jshen wrote: post #85
leshow wrote: post #76

Earlier quoted context omitted.

I'm well aware when they are useful, I've been using them in languages for the past 10 years. By the same token though, leaving type parameters out of the language has had far reaching implications outside of this "narrow" situation (I'll put forth that implementing a data structure isn't a narrow situation). Error handling and the lack of sum types also seem particularly egregious and are heavily influenced by the l…

I’ve been using them for the past 30 years and have come to a different conclusion. You have plenty of languages that do what you want. I hope go doesn’t lose what made it different

You know? Original Java was a fairly simple language :) Generics were added in 2004 in J2SE 5.0.

Re: Generics enabled by default in Go tip

#124

Post by brundolf »

Fire-Dragon-DoL wrote: post #112
jshen wrote: post #80

Earlier quoted context omitted.

I’ve been coding for decades. I’ve used all the fancy functional languages, written production code at scale with complex type systems, etc. my experience, they don’t add a lot of value compared to the costs. In my old age I’ve grown to prefer go for it’s simplicity. I hope we don’t lose it, and you all have the option of using the myriad languages that already do what you are looking for.

I think you misunderstood my point (maybe): I totally agree with you. I've been coding for many years and coming from Ruby where you can do "the worst stuff you can think off" (really bad stuff: monkey patching, building DSL etc.), I came to Go exactly to get relief from all of that. I don't trust people having their hands on all that power. Still in my short Go career, I worked on at least 4 libraries, one of those…

Go has some "special" built in functions like len() that work across different structures. What if instead of adding generics they added more of those special functions for working with slices as you describe? Would that have solved your problem?

Re: Generics enabled by default in Go tip

#125

Post by Fire-Dragon-DoL »

brundolf wrote: post #124
Fire-Dragon-DoL wrote: post #112

Earlier quoted context omitted.

I think you misunderstood my point (maybe): I totally agree with you. I've been coding for many years and coming from Ruby where you can do "the worst stuff you can think off" (really bad stuff: monkey patching, building DSL etc.), I came to Go exactly to get relief from all of that. I don't trust people having their hands on all that power. Still in my short Go career, I worked on at least 4 libraries, one of those…

Go has some "special" built in functions like len() that work across different structures. What if instead of adding generics they added more of those special functions for working with slices as you describe? Would that have solved your problem?

Of course, but remember that `len` has constant return type, while in case of slices you'd have a return type that's different on the input slice

Re: Generics enabled by default in Go tip

#126

Post by SamReidHughes »

deanCommie wrote: post #39
silisili wrote: post #22

Earlier quoted context omitted.

You don't write singly linked lists of arbitrary data :). In my 20+ years of development, I've definitely realized everyone's brains and approaches work differently.

You do if you want your language to have a reusable Linked List data structure so that everyone doesn't have to re-implement their own version of it for each content type.

Linked lists are the one data structure that you never end up wanting a generic version of. They aren't really used as containers. (Except badly.)

Re: Generics enabled by default in Go tip

#127

Post by brundolf »

Fire-Dragon-DoL wrote: post #125
brundolf wrote: post #124

Earlier quoted context omitted.

Go has some "special" built in functions like len() that work across different structures. What if instead of adding generics they added more of those special functions for working with slices as you describe? Would that have solved your problem?

Of course, but remember that `len` has constant return type, while in case of slices you'd have a return type that's different on the input slice

I see. I guess I assumed that the category of special "privileged functions" would have their powers extend to cover stuff like that (I haven't used Go, I'm just going off of what I've read)

I'm very intrigued by the no-generics idea, so I'm prodding at what might've made it workable enough that this reversal wouldn't be necessary :)

Re: Generics enabled by default in Go tip

#128

Post by jagger27 »

jshen wrote: post #95
rustc wrote: post #86

Earlier quoted context omitted.

Are generics really considered as "esoteric comp sci topics"?

If you want coding to be accessible to people without comp sci degrees, and those who are NOT employed as full time developers.

I’m not sure Go has ever been a great language for non-CS people, but it’s been a very long time since I was new to programming. Go is pretty clearly a “get shit done” language catered to developers: a productivity tool. Why should it have its capabilities restricted?

English is used in both reality TV shows and scientific journals. The vocabulary used in the latter doesn’t prevent it from being useful in the former.

Go will still be usable the exact same way it is today after generics are brought in. It’s not like all the existing more approachable code written without generics won’t just disappear overnight.

That said, I agree with GP. Generics aren’t that complex anyway.

Re: Generics enabled by default in Go tip

#129

Post by 1penny42cents »

tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

Isn't that the response you should expect on any topic where the population's preference is split across a decision line?

When go didn't have generics, those in favor commented. Now that it will, those against are commenting.

It sounds funny at face value but I don't see the insight.

Re: Generics enabled by default in Go tip

#130

Post by takeda »

peter_l_downs wrote: post #4

Super excited for this. If you haven't checked out the latest proposal, here's an example of what Option/Result box types might look like (obviously not ready for release, just an experiment): https://go2goplay.golang.org/p/krvTH1_7lwX

I guess I'm understanding some of the concerns. It does make the code harder to understand. I wish they would use the angle brackets to match other languages.
Post reply on HN