4 ms·

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 a

by 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.)

by 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.)