Hacker News Reader

Comment by barnacled | Hacker News Reader

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.

View on HN

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.

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

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

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

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.

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

Reply on news.ycombinator.com