Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>The blog post starts by quoting @kapoorsunny asking why there can't be something like OpenGo, with a community implementation of generics. I hope that it is clear that the answer is that there could be. Nothing prevents that from happening. In particular, Google doesn't prevent that from happening.

No, but like with the community developed dependency solution, Google can arbitrarily chose not to include it in Go, even if itself proves successful.

So it's more like saying "you can have your own niche ports, just don't expect them to become part of the main language".



But this is the same with any open source project - you can write as much code as you want, but if those with the commit bits decide they don't like it, it's not getting upstreamed.

If you were really keen to push some functionality into the Linux kernel, but Linus decided he didn't like it, you'd be in exactly the same position. The fact that in Go's case quite a lot of the maintainers work at Google doesn't really change much.


>But this is the same with any open source project - you can write as much code as you want, but if those with the commit bits decide they don't like it, it's not getting upstreamed.

Yes, but seldom those with the commit bits will so blatantly disregard the community as with the case of the community developed dependency solution (and other cases).

Especially in projects where those with the commit bits are voted, there would be riots...


> The fact that in Go's case quite a lot of the maintainers work at Google doesn't really change much.

It does if those calling the shots aren’t the committers but their bosses.

I’m not saying that’s how it is, but if it is, it changes things a great deal.


It also does since those calling the shots are not just some community members among others that just happened to start the project, but people with job security working on the language, with the money of the biggest sponsor of the language behind them, hosting the infrastructure, doing conferences, and so on.

So it's not a level playing field with another contributor.


That's true for literally any project.


> No, but like with the community developed dependency solution,

Unless you are deliberately trying to obscure the facts. Sam Boyer et al are no unanimously elected community leaders whose solutions somehow must be included with main distribution.

> So it's more like saying "you can have your own niche ports, just don't expect them to become part of the main language".

This is exactly same for all open source languages, if core maintainers do not like the your change either fork it and implement or use any other language which gives you feature you wanted.


>Unless you are deliberately trying to obscure the facts. Sam Boyer et al are no unanimously elected community leaders whose solutions somehow must be included with main distribution.

Unless you are deliberately trying to obscure the facts, this is irrelevant.

Their project seemingly had the blessing of the core team, it was touted as a community effort, it was adopted and tested by the community at large, it was presented and critiqued in public discussions, and so on.

And then it was shot down, unilaterally, and replaced with no discussion by a never before seen implementation from a core team member.

>This is exactly same for all open source languages, if core maintainers do not like the your change either fork it and implement or use any other language which gives you feature you wanted.

Not really, many open source projects give the community a chance to vote on such things, have core team members that are voted into place, and go out of their way to adopt popular community extensions (as opposed to implement their own core-team only versions).


It wasn't arbitrary. The community dependency solution was half-baked: it couldn't support the case of dependencies relying on multiple major versions of the same module. Even Rust is very careful to allow this, and nobody would describe Rust as being anything other than community-led. That this was the issue was made very clear by tye folks who criticized that solution, btw.


This reminds me of the mono project and Microsoft’s .NET languages. It’s doable.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: