7 ms·

While I am a fan of go and like it's simplicity it does sadden me the degree to which it is a 100% google project on any significant change like this. It is not

While I am a fan of go and like it's simplicity it does sadden me the degree to which it is a 100% google project on any significant change like this. It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes. I worked on the compiler in 2011 as an open source contributor and firmly got this impression back then which seriously put me off and the absolute farce of how modules were handled (community heavily involved put a ton of work in then out of nowhere Russ Cox just did his own thing anyway) suggests to me nothing has changed. Generics have been heavily discussed and desired from the beginning of the language and many have contributed thoughts and concepts. At first the designers said more or less 'nope not needed' which changed to 'if somebody suggests a good implementation we will do it'. But would they really? If this design document had come from outside the go team would they even give it a glance? I like the language and the team are clearly talented but it is a pity that the project is quite so proprietary.

coldtea 6y ago
Go appears to be whatever the very small core team says. The rest of the community can help with some (not basic) tooling and libraries, at best.
- barnacled 6y ago
  The thing is I wouldn't mind that and maybe that is what a programming language needs, but they constantly suggest otherwise. The modules situation was pretty shocking to me. Just tell everybody this is how it is and it's all good. I wonder how many people have wasted time suggesting more significant features/changes under the impression they would be listened to?
serial_dev 6y ago
> It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes. While it's might be true that most big changes come from the core team, open source doesn't mean that they have the obligation to merge (and support) extra features they don't think is necessary. Simplicity doesn't just happen, it happens because they reject code that increases complexity and would need to supported and maintained.
- barnacled 6y ago
  No, not most, all. Projects like the Linux kernel are equally highly selective and reject code that they don't like big or small, but they do at least sometimes accept significant changes. As I responded in another comment, I accept that might be necessary to maintain the approach of the language but the go team seriously misrepresent this. That is my main issue with them. How many people have put a lot of work in only to find out that actually the go team aren't accepting significant patches? Look to the go modules fiasco for a good example of this. Honesty matters.
  - clktmr 6y ago
    The Linux kernel is very different in this regard. Changes can be reverted easily. A change to the Go language will propagate quickly in it's users projects and probably stick with you forever.
    - a1369209993 6y ago
      > The Linux kernel is very different in this regard. Changes can be reverted easily. Only if nothing in userspace (the equivalent of "[Go]'s users projects") has started to depend on it. A OS kernel is perhaps slower than a programming language to see uptake of new features, but the dependencies are still there.
    - barnacled 6y ago
      Sure, but as I've said a couple times already, the issue is that the go team have indicated they _would_ accept major changes (they explicitly said they would on generics for a long while, which I suggest is just not true, and actually had people work on modules stuff then just stiffed them with their own solution - See Sam Boyer's (long) twitter thread on the whole go dep thing - https://twitter.com/sdboyer/status/1034893100450291713 https://twitter.com/sdboyer/status/1034893100450291713). Either they should say 'nope the BDFL accepts nothing significant except from the go core team' or they should change their ways. You can't have both. Obviously other languages do manage the balance - eg. python, rust, so it's possible but I totally accept that given go's minimalism and opinionated approach they might not want that. But be honest about it. And good luck reverting a released kernel buried on a server :) especially once users start relying on e.g. a syscall. You might find that it's not quite as different as you want it to be...
02020202 6y ago
i am no fan of gulag and i do not like the ties of go to gulag but i think it is not as bad as gulag monopolizing the web browser industry. also i think that people running the project are way smarter than any of us and the community argument is not a good one, for me. because if someone does not do the gatekeeping the language would become yet another bloated "modern" monstrostity with all the batteries included. also i think a programming language should not even have a community when it comes to development. it should all scientifics papers and top brains working on it and not anyone with github account. since this is the most basic brick in the entire software chain, there is no place for politics, feelings, quick fixes and cleverness. the language should be a "perfect" too that does only one thing but it does it incredibly well.
papaf 6y ago
It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes. It is absolutely an open source project. However, it is closer to Cathedral style development rather than Bazaar [1]. [1] https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
- barnacled 6y ago
  that's why I said 'in the sense of most other major OSS projects' :) Most well-known projects operate in the bazaar model and the Go team claim to also but in fact are operating a cathedral.
geodel 6y ago
Maybe you are just concerned with Go, but there are similar instances in Java, Swift, Rust and maybe others too. Every big company sponsored language is like that. > I like the language and the team are clearly talented but it is a pity that the project is quite so proprietary. To me it seems like nature of things. People who are talented and in control are just not going to take any contribution come their way. For people outside if their thinking aligned with core team they will feel welcome and others will feel unwelcome due to high handedness of core team.
- Cthulhu_ 6y ago
  I dunno about Java, it's often cited as a design-by-committee failure of a language, and it took years to escape it. It did not have a singular owner but a number of very large, very bureaucratic and very rich companies with vested interests. In my outsider's perspective, this caused the language to effectively deadlock for the better part of a decade. Go in the meantime is chooching along gradually, trying hard not to do anything too big in one go. Modules was the big thing this year, and people are still adjusting and transitioning. Generics MIGHT be the next big thing (idk if the draft design is finished, approved, and work on implementing it is underway). But they spent years considering, humming and hawing, objecting, polling and reconsidering this particular one. They could have pushed for it much harder and much earlier on, but they wanted for the language to settle first, for use cases to be discovered, etc. They learned from the past, e.g. Java's implementation, and how it added so much complexity to the language spec, compiler, and all the build tooling - which they really wanted to avoid, because of the use cases of Go as a language and the problems it wanted to avoid (including complicated and slow compilation).
  - geodel 6y ago
    Java had /EE part which was much more designed by committee. Oracle last year dumped that on to Eclipse foundation. Now Java release is every 6 months like Go and it looks lot less designed by committee.
- yakubin 6y ago
  > Maybe you are just concerned with Go, but there are similar instances in Java, Swift, Rust and maybe others too. Every big company sponsored language is like that. How is that true about Rust? Mozilla fired people working on Rust. Now there's a foundation and from the looks of it there are lots of contributions from individual contributors coming through GitHub.
tacitusarc 6y ago
I remember reading the proposal from a couple years back and disliking it immensely. I and many others left feedback to that effect, and this updated draft document reflects that feedback. I think the go team has messed up packaging because they didn't correctly understand the problem space, but the multi-year effort to deeply understand parametric polymorphism means this draft is actually quite reasonable. I, for one, am excited for this addition to the language.
yencabulator 6y ago
godep deserved to be scrapped for purely technical reasons (no matter how much the people who wrote it whine about it). Do you have a second example?

coldtea 6y ago

Go appears to be whatever the very small core team says. The rest of the community can help with some (not basic) tooling and libraries, at best.

barnacled 6y ago
The thing is I wouldn't mind that and maybe that is what a programming language needs, but they constantly suggest otherwise. The modules situation was pretty shocking to me. Just tell everybody this is how it is and it's all good. I wonder how many people have wasted time suggesting more significant features/changes under the impression they would be listened to?

serial_dev 6y ago

> It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes. While it's might be true that most big changes come from the core team, open source doesn't mean that they have the obligation to merge (and support) extra features they don't think is necessary. Simplicity doesn't just happen, it happens because they reject code that increases complexity and would need to supported and maintained.

barnacled 6y ago
No, not most, all. Projects like the Linux kernel are equally highly selective and reject code that they don't like big or small, but they do at least sometimes accept significant changes. As I responded in another comment, I accept that might be necessary to maintain the approach of the language but the go team seriously misrepresent this. That is my main issue with them. How many people have put a lot of work in only to find out that actually the go team aren't accepting significant patches? Look to the go modules fiasco for a good example of this. Honesty matters.
- clktmr 6y ago
  The Linux kernel is very different in this regard. Changes can be reverted easily. A change to the Go language will propagate quickly in it's users projects and probably stick with you forever.
  - a1369209993 6y ago
    > The Linux kernel is very different in this regard. Changes can be reverted easily. Only if nothing in userspace (the equivalent of "[Go]'s users projects") has started to depend on it. A OS kernel is perhaps slower than a programming language to see uptake of new features, but the dependencies are still there.
  - barnacled 6y ago
    Sure, but as I've said a couple times already, the issue is that the go team have indicated they _would_ accept major changes (they explicitly said they would on generics for a long while, which I suggest is just not true, and actually had people work on modules stuff then just stiffed them with their own solution - See Sam Boyer's (long) twitter thread on the whole go dep thing - https://twitter.com/sdboyer/status/1034893100450291713 https://twitter.com/sdboyer/status/1034893100450291713). Either they should say 'nope the BDFL accepts nothing significant except from the go core team' or they should change their ways. You can't have both. Obviously other languages do manage the balance - eg. python, rust, so it's possible but I totally accept that given go's minimalism and opinionated approach they might not want that. But be honest about it. And good luck reverting a released kernel buried on a server :) especially once users start relying on e.g. a syscall. You might find that it's not quite as different as you want it to be...

02020202 6y ago

i am no fan of gulag and i do not like the ties of go to gulag but i think it is not as bad as gulag monopolizing the web browser industry. also i think that people running the project are way smarter than any of us and the community argument is not a good one, for me. because if someone does not do the gatekeeping the language would become yet another bloated "modern" monstrostity with all the batteries included. also i think a programming language should not even have a community when it comes to development. it should all scientifics papers and top brains working on it and not anyone with github account. since this is the most basic brick in the entire software chain, there is no place for politics, feelings, quick fixes and cleverness. the language should be a "perfect" too that does only one thing but it does it incredibly well.

papaf 6y ago

It is not an open source project in the sense of most major open source projects and if you don't work at Google on the go team you are highly unlikely to be involved in any significant changes. It is absolutely an open source project. However, it is closer to Cathedral style development rather than Bazaar [1]. [1] https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

barnacled 6y ago
that's why I said 'in the sense of most other major OSS projects' :) Most well-known projects operate in the bazaar model and the Go team claim to also but in fact are operating a cathedral.

geodel 6y ago

Maybe you are just concerned with Go, but there are similar instances in Java, Swift, Rust and maybe others too. Every big company sponsored language is like that. > I like the language and the team are clearly talented but it is a pity that the project is quite so proprietary. To me it seems like nature of things. People who are talented and in control are just not going to take any contribution come their way. For people outside if their thinking aligned with core team they will feel welcome and others will feel unwelcome due to high handedness of core team.

Cthulhu_ 6y ago
I dunno about Java, it's often cited as a design-by-committee failure of a language, and it took years to escape it. It did not have a singular owner but a number of very large, very bureaucratic and very rich companies with vested interests. In my outsider's perspective, this caused the language to effectively deadlock for the better part of a decade. Go in the meantime is chooching along gradually, trying hard not to do anything too big in one go. Modules was the big thing this year, and people are still adjusting and transitioning. Generics MIGHT be the next big thing (idk if the draft design is finished, approved, and work on implementing it is underway). But they spent years considering, humming and hawing, objecting, polling and reconsidering this particular one. They could have pushed for it much harder and much earlier on, but they wanted for the language to settle first, for use cases to be discovered, etc. They learned from the past, e.g. Java's implementation, and how it added so much complexity to the language spec, compiler, and all the build tooling - which they really wanted to avoid, because of the use cases of Go as a language and the problems it wanted to avoid (including complicated and slow compilation).
- geodel 6y ago
  Java had /EE part which was much more designed by committee. Oracle last year dumped that on to Eclipse foundation. Now Java release is every 6 months like Go and it looks lot less designed by committee.
yakubin 6y ago
> Maybe you are just concerned with Go, but there are similar instances in Java, Swift, Rust and maybe others too. Every big company sponsored language is like that. How is that true about Rust? Mozilla fired people working on Rust. Now there's a foundation and from the looks of it there are lots of contributions from individual contributors coming through GitHub.

tacitusarc 6y ago

I remember reading the proposal from a couple years back and disliking it immensely. I and many others left feedback to that effect, and this updated draft document reflects that feedback. I think the go team has messed up packaging because they didn't correctly understand the problem space, but the multi-year effort to deeply understand parametric polymorphism means this draft is actually quite reasonable. I, for one, am excited for this addition to the language.

yencabulator 6y ago

godep deserved to be scrapped for purely technical reasons (no matter how much the people who wrote it whine about it). Do you have a second example?