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

Golang proposal: container/: generic collection types

github.com

Post reply on HN
Print view View original

131–140 of 207 posts

Re: Golang proposal: container/: generic collection types

#131

Post by Hendrikto »

cyphar wrote: post #8
pstuart wrote: post #4

Earlier quoted context omitted.

Sounds like a win to me. I'd assume that many PL decisions come with with costs of either implementation or readability, and Go's conservative evolution takes that into account. Disclaimer: not a PL designer, just a codemonkey. It's not a perfect language, and the process has not been without its pain points, but work like this makes the language more powerful and I feel like I get my money's worth when I use it. Yes…

On the other hand, design decisions made under one set of constraints can become problematic when you add new features that don't play as well with earlier design decisions. For a concrete example, the fact you cannot define custom methods for external types in Go (a pre-1.0 design decision) means that you cannot write proper compile-time generic code to deal with some generic wrapping type (dumb example -- getting a…

> the fact you cannot define custom methods for external types in Go

Just wrap them. The external type is theirs. Make your own wrapper and do whatever you like with it.

People want every language to adapt to them, instead of adapting themselves to the language.

Re: Golang proposal: container/: generic collection types

#133

Post by bheadmaster »

DarkNova6 wrote: post #62

Step by step, Go is now learning the hard lessons every other language has learned over the last 20 years. The fact that despite their best efforts, their propositions look like everone else is a surprisingly refreshing affirmation of status quo.

Language is more than just its syntax and features.

The most important "features" of Go are fast compilation, orthogonality of features, and easy development.

Their propositions may "look like everyone else" if you're only looking at surface syntax, but there's a reason why it took 10 years to design an acceptable generics proposal, and the result is that compiling generic-heavy code is almost as fast as compiling plain Go.

Go being strict about features it accepts is not an ideological thing, but a practical one. If Go could have all the features in the world while still being easy to use, fast to compile, and internally coherent, it would. But it can't (see: C++, C#, Python).

Re: Golang proposal: container/: generic collection types

#134

Post by tzone »

kamma4434 wrote: post #98

Welcome to Java, where Collections are the bread and butter of every programmer since 1998. While you are at it, I humbly suggest to add composable streams too, that we had in 2014, and that make working with collections way more pleasant. (Jokes aside, in Java it is very nice that you can start with a generic ArrayList and turn it into a linked list with one single keyword change and no code needs changing, or that…

People use Go vs Java not because of the language differences but because of massive improvement that GO runtime is compared to JVM.

It is crazy that people still don't understand why JVM sucks, and why GO's approach to minimize GC pause latency is far superior design decision compared to whatever JVM has been trying to do with its GC iterations for god knows how many years with gazzillion different variants that all suck in different ways.

Re: Golang proposal: container/: generic collection types

#136

Post by hwc »

DarkNova6 wrote: post #62

Step by step, Go is now learning the hard lessons every other language has learned over the last 20 years. The fact that despite their best efforts, their propositions look like everone else is a surprisingly refreshing affirmation of status quo.

On the other hand, I've found that for every real-world application I've written in Go, I have not found myself missing any of the containers C++ has had since 2003. I didn't really ever need generics either. I only use them to make it to make it clear which functions don't rely on specific properties of the type they operate on.

Yes, there are occasionally really good reasons to use an ordered map or a priority queue, but I haven't needed either in years.

Re: Golang proposal: container/: generic collection types

#137

Post by hwc »

farfatched wrote: post #80
DarkNova6 wrote: post #75

Earlier quoted context omitted.

I totally get that. Java is my favorite language for exactly that reason. They are a deliberate "late mover language" and adopt what other languages have proven right. But looking at how adamant Go used to be on the whole "No Generics" stance and the path and the troubles they are having... it all seemes so preventable?

I think it was. Go without generics was ok. I say that as a fan of generics in other languages. There is room for languages with simpler feature sets. It takes a strong leader (and the good and bad that comes with that) to continue to deny features. Go had that. Does it still? (I genuinely don't know.) I'm not sure what Go's value proposition is now. Developers can't pick it up in a week, as it used to be. Maybe that…

> Developers can't pick it up in a week...

I don't think any of the new additions to the library have seriously made the learning curve more difficult. I suspect that most projects don't use templates at all.

There have always been parts of the standard library I'm not familiar with. when I read code that uses it, I just go read the documentation. Now the standard library is just larger.

Re: Golang proposal: container/: generic collection types

#138

Post by epolanski »

vander_elst wrote: post #135

I find it so sad that people wasted millions of hours and lines of code rewriting over and over basic constructs that should have been on the language in the first place. How many years before we finally get sum types?

It's not like your idea is bad, is that each abstraction eats in one of the fundamental strengths of Go (simplicity and compilation times).

Re: Golang proposal: container/: generic collection types

#139

Post by inigyou »

brokencode wrote: post #71
inigyou wrote: post #67

Earlier quoted context omitted.

my criticism is that if we make every language identical, we might as well only have one language. (C++, obviously) There is room for a language without generics. There was a language without generics. Now there is not.

Well here’s the thing on generics. Go always had generics since the very beginning. It’s just that only certain built-in types had them. Slices, maps, and channels all were generic from day one. Same with functions like append, copy, etc. Your criticism makes no sense unless you think Go shouldn’t have had generics from the start, which it did.

By that logic C has generics because pointers are a generic type - you can have a pointer to any type you want.

Re: Golang proposal: container/: generic collection types

#140

Post by ndriscoll »

win311fwg wrote: post #118
Sleaker wrote: post #79

Earlier quoted context omitted.

And this is -exactly- one of the reasons they didn't accept or continue with a sane proposal for more ergonomic error handling. I like go, but this was the one thing that I kept feeling like I was wasting so much time dealing with.

Presumably you are referring to https://github.com/golang/go/discussions/71460 ? While the proposed slightly reduced the token count, saving the average typist approximately 1 second of time if they don't have an autocomplete editor that types it for them, it doesn't change anything about the mental model where the real time is actually spent, so is it really sane? Worse, it is dependent on the error type, but errors…

Reducing syntactic noise is about legibility, not writing ease. The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute.

Of course if you want something less specific to errors, we already have do-notation as an excellent example to look at. And you can't say that's more complex for users than what they did with iterators.

Post reply on HN