The story is that the Go designers saw the value in generics and added a bunch of generic container types to the language. They are also saying that if your needs aren't covered by these built-ins, then you have to build something on your own and you cannot construct something that provides the safety and ease of the built-ins.
> a variety of complex programs are being built and deployed in Golang without generics, which makes it an open question as to whether they're required at all.
And a variety of complex programs have been built and deployed in assembler. There are arguments against adding generics, but the fact that people get by without them isn't a convincing one.
The story is that generics for Go is an ongoing research project for the team. We are not going to put them into the language until we are sure that we have a satisfactory way of doing it and that the end result is a net win.
>The story is that generics for Go is an ongoing research project for the team.
I don't see that in real life. That's just a "shut up" story employed like 4 years ago. If it's an "ongoing research" project, where's any researchy output?
"Python 3000" was once a research project and had tons of proposals and research done on various features. Closures in Java were researched, and there were implementations tested. ES6 was an ongoing effort to add features to Javascript, and there have been test implementations, shims, etc before it's out.
All languages that wanted to add a feature had attempts by various key developers to add these to them, proposals, papers, testing, requests for comments, etc. Where are those regarding Go and generics?
The various proposals have been circulated amongst a small group of core Go contributors. That has been sufficient to drive the process so far, with many options being explored in detail. The work continues to evolve.
We're not university professors. We're not publishing papers or other "researchy output". We're just trying to get stuff done. If we publish all the works-in-progress we will distract the community from the more pressing concerns of today's Go programmers. We all already spend way too much time reading mail, and generics is a hot topic (obviously). The last thing we need is more (redundant) mail.
>We're not university professors. We're not publishing papers or other "researchy output".
Well neither is Larry Wall, or Guido (well, is not working directly as such), or the Rust guys. But they still manage to put out proposals and describe their approaches to adding features, their progress and such.
I didn't mean "researchy output" in the academic sense. Just the results of looking into it, basically. Could be just a blog post. Or some email.
Well, I'm sorry, but I haven't seen this from following Go from a (small) distance -- and doing some work projects with it.
Perhaps those people working on it can give an update or some info on their work? Even a "we tried this approach, it's too cumbersome so we abandoned it" or "we pursue this idea, but we're still ways off" etc, would suffice.
Aren't you just kinda being a dick here? A go developer has directly responded to you multiple times, saying that this is a topic that they're actively researching. And you just keep replying with skepticism asking for actual proof.
No one owes you anything here. I hope you don't behave this way with other open source projects.
>And you just keep replying with skepticism asking for actual proof.
Should I just accept the same kind of answer we've had for 4 years on the Go webpage, and move on?
You talk about wanting "actual proof" as if it's a bad thing. Where's the harm in wanting "actual proof"? Did Ken Ham proved it overrated?
Notice how the top voted comment in this thread, showing a clear community interest, makes the same point:
"I'm surprised at the lack of progress in generics for Go. But more than progress, I'm surprised at the lack of a story about generics in Go. Yes, the FAQ waves its hands at complexity, but the lack of discussion and/or proposals puzzle me."
>No one owes you anything here.
That doesn't preclude discussion, having questions and, yes, even doubting overly generic answers. Noone owes anything to the Python community either, but they are far more open with such things.
Perhaps I want to know if Go wants to be a real community project, or a "developed by a core team at Google in secrecy you get what we want you to get when we want you to get it" thing.
>Yes. Clearly its time to find another language that better suits your needs and is managed more to your liking
Isn't that like a really inadequate answer to people trying to critisize/improve things? I sure get the rednecky "If you don't like this country mister, then go live somewhere else" vibe from it.
Clearly the fact that you are satisfied with Go doesn't stop you from inteferring with people having discussions about its (perceived) shortcomings.
So why should my disatisfaction with it prevent me from discussing it Especially if its a dissatisfaction with some aspects of it, and not the whole thing? By the same logic, nobody should use anything (nor complain about anything), since all languages have shortcomings that they don't like.
You've misread my comments and are trying to make them into something they're not. I wasn't calling you out for criticizing Go or trying to discuss its shortcomings. I was calling you out for being a dick to Enneff. I think my original comment was fairly clear about this.
Anyways this is a pointless argument. I'm sure youre a great guy in person.
>You've misread my comments and are trying to make them into something they're not. I wasn't calling you out for criticizing Go or trying to discuss its shortcomings. I was calling you out for being a dick to Enneff.
Well, we appreared as representing the Go team, and then rehashed the old "we're actively looking into it" response. I was not trying to be a dick, just wanted something more concrete than that.
Plus, I felt like he contradicted himself, when replying to another comment and said something to the effect that they didn't do anything about generics because they are busy building other things. So I had to ask, which was it, were they actively looking into it or didn't have time and had it as a low priority?
> a variety of complex programs are being built and deployed in Golang without generics, which makes it an open question as to whether they're required at all.
And a variety of complex programs have been built and deployed in assembler. There are arguments against adding generics, but the fact that people get by without them isn't a convincing one.