3 ms·

> 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

> 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...
  - xorcist 6y ago
    Linux very famously does not break user space. The has been very few exceptions historically for serious bugs, executables should run no matter how old they are. Even after migrating to a new executable format, Linux still has optional support to load the old format some 25 years later. In comparison, Go does breaking changes from time to time, but it is also a much younger project. In general, comparing a language syntax with an api is hard to draw meaningful conclusions from.
    - remus 6y ago
      > In comparison, Go does breaking changes from time to time, but it is also a much younger project. In general, comparing a language syntax with an api is hard to draw meaningful conclusions from. Could you give some examples? I would say go has a very high standard of backwards compatibility (to a fault, even. Many good changes are not merged because they could break existing go programs.)

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...
- xorcist 6y ago
  Linux very famously does not break user space. The has been very few exceptions historically for serious bugs, executables should run no matter how old they are. Even after migrating to a new executable format, Linux still has optional support to load the old format some 25 years later. In comparison, Go does breaking changes from time to time, but it is also a much younger project. In general, comparing a language syntax with an api is hard to draw meaningful conclusions from.
  - remus 6y ago
    > In comparison, Go does breaking changes from time to time, but it is also a much younger project. In general, comparing a language syntax with an api is hard to draw meaningful conclusions from. Could you give some examples? I would say go has a very high standard of backwards compatibility (to a fault, even. Many good changes are not merged because they could break existing go programs.)