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

111–120 of 207 posts

Re: Golang proposal: container/: generic collection types

#111

Post by pjmlp »

pstuart wrote: post #43
improgrammer007 wrote: post #31

First they said they won't add generics. They violently defended that decision. Developers bent over backwards to make it work without generics. Some even wrote long blog posts defending Rob Pike's decision. Some wrote posts arguing against it. Now the Golang team adds them. Why waste so much developer time? It's not a few months. It's several years. This industry is seriously a clown show tbh.

Core members of the language team (Robert Griesemer and Ian Lance Taylor) argued for generics from the very beginning. The team resisted because they didn't know how to do it without sacrificing speed of compilation. Rob Pike did a lot of defensive work to deflect it but I'll quote him here on the issue when he said "There are no plans for generics. I said we're going to leave the language; we're done": "I meant ther…

You mean how Ada, Delphi, D, OCaml compile?

Re: Golang proposal: container/: generic collection types

#112

Post by pjmlp »

znpy wrote: post #64
throw_m239339 wrote: post #44

Earlier quoted context omitted.

Nothing wrong with J2EE back then if you were building a certain kind of entreprise application. EJBeans actually took care about a lot of business complexity for a n-tier application, it's just that the whole XML crap was absolutely egregious. Go can barely parse an XML document natively so don't worry about G2EE I'd say... I'm more worried about what have become of professional Javascript serverside these days, it'…

Absolutely, i was just being ironic :)

What do you think Kubernetes is?

Go EE is the plethora of CNCF projects.

Re: Golang proposal: container/: generic collection types

#113

Post by win311fwg »

pjmlp wrote: post #105
win311fwg wrote: post #83

Earlier quoted context omitted.

Does it? It was only preventable by not releasing Go, which isn't exactly the greatest of solutions. As you know from when Go was first broadcast to the world, they hadn't figured out how to make generics fit[1]. It is not like they weren't trying. Ian Lance Taylor is regarded for beginning work on generics before anyone outside of Google had even heard of Go. "In short: not yet" What was surprising is that after Go…

More like no one on the world was able to change their mind, and then they had to ask help to someone that could already have provided help before Go released 1.0 version. "They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU an…

Quite right. If the Go team somehow magically had the right technical background Go would have had generics earlier, but they didn't and weren't going to magically get it, so we're back to the only preventable way was to not release it at all.

But one would think that of the billions of people in the world that someone outside of the Go team would have had that familiarity to quickly change that, but no proposals came from that direction for over a decade and a lot of begging. I suppose those who had the chops were too busy constantly posting on HN about how Go doesn't have generics to lend their expertise. Priorities.

It's great to reflect back in hindsight about where you failed, but it's always easy to see where you failed after someone else finally shows you the way. The simple fact that the Go team did not have the technical capability to be able to add generics at the time remains. Being able to create a relatively popular programming language (or set of popular programming languages for some of them) certainly does not imply that you are a programming language expert. There may even be an inverse correlation. Those who show to be programming language gods appear most likely to end up creating esoteric languages that end up on the pile of languages that remain unknown and unused.

Re: Golang proposal: container/: generic collection types

#114

Post by shikck200 »

DarkNova6 wrote: post #75
somekyle2 wrote: post #66

Earlier quoted context omitted.

I respect "we're going to try not to add features until we have to and have a plan that we like" as an approach to a practical language, vs "we're going to plan to support everything normal modern languages have". It isn't the best approach to language design in theory, but they did try to build a language that isn't impossible to change, and to be fair the mix of language features they chose didn't have any good mor…

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?

Go never was "no generics". It had generics rusted in from the get-go, but never implemented them as it was a complex feature and one that made the compiler slower. Im glad they waited. Compare to PHP, where every feature is bolted on and then you end up supporting it forever.

Re: Golang proposal: container/: generic collection types

#115

Post by shikck200 »

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…

Java? No thanks. I have some horrible memories from the ugliness, verbosity of Java. The cherry on the cake is the huge hog of an runtime called the JVM. Also java semi-forces you to have some bulky IDE. Last i looked there was no core java lsp server bundled in the tooling.

Java is the enterprise language that make programming suck.

Re: Golang proposal: container/: generic collection types

#116

Post by wannabe44 »

tyre wrote: post #93
wannabe44 wrote: post #7

Earlier quoted context omitted.

Map function leads to poor code in Go. Function literals are verbose and inlining is far less agressive. It simply isn't the way of the language. Even python shuns map and filter in favor of comprehensions. A for loop is more readable than the lambda soup.

Python uses comprehensions because whitespace sensitivity was a horrendous language decision, then couldn’t find a way to support multiline lambdas. Comprehensions are not a well-designed feature but a consequence of poor design.

Comprehensions are way cleaner and more optimizable for the common case.

Re: Golang proposal: container/: generic collection types

#117

Post by pjmlp »

win311fwg wrote: post #113
pjmlp wrote: post #105

Earlier quoted context omitted.

More like no one on the world was able to change their mind, and then they had to ask help to someone that could already have provided help before Go released 1.0 version. "They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU an…

Quite right. If the Go team somehow magically had the right technical background Go would have had generics earlier, but they didn't and weren't going to magically get it, so we're back to the only preventable way was to not release it at all. But one would think that of the billions of people in the world that someone outside of the Go team would have had that familiarity to quickly change that, but no proposals cam…

Go is basically a mix between Oberon-2 and Limbo, which we all know where they landed on the adoption curve.

Without the adoption success of Docker and Kubernetes adding wind to Go's sails, Go would have landed on the island.

They were not lacking in skills, rather politics, and there is a public talk from Rob Pike where he mentions even the Go 1.18 generics would not have landed if it was for him.

Re: Golang proposal: container/: generic collection types

#118

Post by win311fwg »

Sleaker wrote: post #79
vlovich123 wrote: post #72

Earlier quoted context omitted.

The problem is that when you don’t have a cohesive picture of how things fit from the outside, it becomes really hard to evolve the language in a way that makes sense and doesn’t break existing code. Data storage and languages share this unique property that the past impacts your decisions and what makes is possible in the future in a way pure logic doesn’t struggle with.

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 are not always of the error type. Not even Go's own standard library consistently returns errors using the error type, never mind all the other crazy things you find in the wild.

That doesn't sound sane at all.

It is true that Go not having any real kind of superpositions or side channels makes stealing popular ideas from other languages impossible (it already has both well-known error handling methods that do not depend on those properties). But a sane proposal would be designed with that in mind.

Re: Golang proposal: container/: generic collection types

#120

Post by win311fwg »

pjmlp wrote: post #117
win311fwg wrote: post #113

Earlier quoted context omitted.

Quite right. If the Go team somehow magically had the right technical background Go would have had generics earlier, but they didn't and weren't going to magically get it, so we're back to the only preventable way was to not release it at all. But one would think that of the billions of people in the world that someone outside of the Go team would have had that familiarity to quickly change that, but no proposals cam…

Go is basically a mix between Oberon-2 and Limbo, which we all know where they landed on the adoption curve. Without the adoption success of Docker and Kubernetes adding wind to Go's sails, Go would have landed on the island. They were not lacking in skills, rather politics, and there is a public talk from Rob Pike where he mentions even the Go 1.18 generics would not have landed if it was for him.

> Go is basically a mix between Oberon-2 and Limbo, which we all know where they landed on the adoption curve.

Exactly. You might say that Wirth, Mössenböck, and Winterbottom had some programming language chops, bringing some new ideas to the world, which is in line with the observation that those with programming language skills end up creating languages nobody uses. In fairness, Pike was involved in Limbo, but his only claim to fame was pressuring Winterbottom to add garbage collection to Alef, thus Limbo.

> Without the adoption success of Docker and Kubernetes adding wind to Go's sails, Go would have landed on the island.

Fun story, but no. Those projects chose Go because Go had already gained traction and was thought, in that moment in time, that it was going to be the way of the future.

It is true that Docker is often credited as the first major success story, but Hugo, etcd, InfluxDB, etc. were all released around the same time, never mind the long list of projects that never gained popularity. The language was already being widely used by the time Docker showed up. Go didn't need a major success story to get on the radar. It had Google's marketing power behind it, or at least that's why most believe it was able to become popular without having any breakouts to its name.

> They were not lacking in skills, rather politics

These are not separable concepts. Politics are the result of lack of skill.

Post reply on HN