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

141–150 of 378 posts

Re: Generics enabled by default in Go tip

#141

Post by SPBS »

tapirl wrote: post #104
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

Each Unwrap() call needs two OK() calls? Letting Unwrap return OK would be better? BTW, the readability is really not good as Go 1.

As it rightfully should. God forbid people start returning Result[T] types instead of (T, error) and splintering the ecosystem.

Option types are pointless if you don't have exhaustive pattern matching to ensure correctness.

Re: Generics enabled by default in Go tip

#142

Post by masklinn »

mseepgood wrote: post #106
pm90 wrote: post #90

Earlier quoted context omitted.

Go is still pretty “simple”. They didn’t introduce a while loop. Adding generics would arguably “simplify” the language even further since you would presumably throw away a lot of duplicated code.

They can simplify code, but they don't simplify the language.

The langage which already had generics except special-cased to builtins the langage authors really wanted to be generic and they know better than the peons so they have the intellectual capacity to make this determination?

Re: Generics enabled by default in Go tip

#144

Post by doctor_eval »

theshrike79 wrote: post #92
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…

I have seen terrible and unreadable generic code, people building abstractions just for the sake of abstractions. Hello-world level projects with 20 class deep hierarchies of generic classes, just to make it "generic" in case you need it later.

I agree. It’s true for all languages. I once had to untangle a small Java app that had about five packages with two classes per package (I refactored it into a single package).

Some people will abuse generics, no doubt, just like my colleague abused packages. But Go has such a strong culture around idiomatic code that I’m not too worried that generics are the end of the world. In fact, I don’t like keywords like “append” and I’m hopeful generics will replace them.

TBH I was more upset about the Go 1.17 ability to panic during a type conversion from slice to array pointer. That one really grates my gears.

Re: Generics enabled by default in Go tip

#145

Post by silisili »

AnimalMuppet wrote: post #79
silisili wrote: post #14

Earlier quoted context omitted.

Neither, of course. I'll leave so you can join. I don't think either of us is wrong.

You sound like, for you personally, generics are like a poison atmosphere. You simply can't live in that environment. Why? Why so negative? I work in C++. Generics exist there. I don't use them except for some STL containers. I just... don't use them. I don't have problems where I need them. How does it hurt me if they exist? You may say that someone else will use them, and make your code more unreadable. They may, b…

I don't mean to be negative only, and appreciate your reply.

But I know what happens in real codebases. Before long, scammy tutorials pop up showing Go as an essentially dynamic language, and that's what bootcampers write. As of today, they are forced to write simple, boring code.

I never mind a carefully added thing, for carefully thought of situations, as this probably was.

The problem is that I see the abuse from here. And even if not abuse, it changes how you approach problems. And approaches matter as much or more then spec.

I knew a person who insisted on a lot of things when working in a Go code base...one of which was mixed typed tuples. It was ugly, awful code of interfaces all the way down. It's ugly and Go let you know that. A voice of reason would say...what are you doing? That's not how you do it in Go.

Readability goes beyond the syntax. It's a mindset. And now it's not.

Re: Generics enabled by default in Go tip

#146

Post by tptacek »

takeda wrote: post #139
bopbeepboop wrote: post #117

Earlier quoted context omitted.

You changed function signatures from int->bool to uint->bool, which changes how long the functions are. That seems unfair when comparing: Removing negatives from the Go implementation removes 6 out of 16 lines, bring it from 3x Rust to 2x Rust in line length.

I used code from: https://endler.dev/2017/go-vs-rust/ good point, I overlooked that. Anyway in Go (ironically because of lack of generics) if you use any numeric type other than int, int64, float64 you will be in the word of hurt. Rust doesn't have that issue. So in practice you will likely use int, and I suppose you can add an assertion. BTW: I only see that it would remove 3 lines though, where are the other 3?

I don't follow. I use unsigned ints in Go all the time. I've never been in a world of hurt with them. Mandatory explicit integer conversions (and the way Go consts work) are something Go gets right.

Re: Generics enabled by default in Go tip

#147

Post by masklinn »

evanmoran wrote: post #115

This is actually my first week using go (from years of C++/Swift/js/etc) and I’ve been very impressed with the module system and simplicity so far. I’d definitely encourage others to try it if they haven’t. As for generics, Go’s lack of function overloading and arg default values is really interesting. It ensures that a function is always easily found as it’s the only thing in the module with that name. I’ll be curio…

> As for generics, Go’s lack of function overloading and arg default values is really interesting. It ensures that a function is always easily found as it’s the only thing in the module with that name. I’ll be curious to see if generics are easier to follow without function overloading.

There are already a number of langages with generics and without overloading (or defaults). Haskell, ocaml, rust, …

Re: Generics enabled by default in Go tip

#148

Post by tptacek »

dehrmann wrote: post #120
tptacek wrote: post #23

Earlier quoted context omitted.

You wouldn't. Everybody goes into Go thinking that's absurdly confining. Some significant subset of Go programmers learn that they instead find it liberating. Programming is programming; you have an overwhelming number of degrees of freedom no matter what language you work in. It sometimes turns out that taking some of those degrees out of the language makes it easier to focus them on your problem domain.

> You wouldn't As someone who hasn't used Go, what would I do, then? The question about a generic data structure was very practical, your response was philosophical, and I still need a linked list.

You would use a slice as your non-associative container, and you would write a loop over it. You just wouldn't use a linked list.

Re: Generics enabled by default in Go tip

#149

Post by masklinn »

takeda wrote: post #133
brundolf wrote: post #43

I've never used Go, and from the outside I take a lot of issues with its design choices. But even without having used it I always thought the lack of generics was very interesting and I could see how it was desirable. It's fascinating to me that Go has gotten as far as it has without them (proving that it's possible to), and the mindset shift people describe having around them seems like a really important thing to p…

Java didn't have generics until version 5. They were added 8 years later.

c# was also released without generics, they wanted it out the door and the generics were not ready. They landed in 2.0.

Re: Generics enabled by default in Go tip

#150

Post by pkulak »

lokedhs wrote: post #73
silisili wrote: post #9

Not to be contrary for its sake, but I'll say this is one change I'm really not happy about. I feel like it's a change to placate many, while driving a lesser amount away. Which is fine, but still feels like the end of something, as I am one of the aforementioned 'lesser.' As for why...I love above most the simplicity and readability of Go. Any change which encroaches that, which this does, is a net negative to me.

Back when generics were introduced to Java I felt the same thing. I had been doing Java for years at that time. I had also been working for Sun, so of course I was exposed to it. I was very negative towards generics and had similar arguments as you. It didn't take long before I changed my mind. I'd never want to write Java without generics again. I'm not saying you're going to have the same experience, but I would su…

Does Go generics have type erasure? If not, OP can expect and even better journey.
Post reply on HN