[Merovius]

> they seem to focus their decisions on small-ish scale projects at the expense of large / longer-term ones, and this is the natural consequence.

This is - excuse me - a pretty ridiculous claim, given the explicit design goals of go. https://talks.golang.org/2012/splash.article You might disagree, that their choices are furthering these design goals (I don't), but claiming that they focus on small-ish projects is just non-factual, most design decisions are driven by a focus on large (both in problem- and code size) projects.

> A lot of the problems are solved by "hit it until it compiles"

Neither do I want to need to fix compilation errors in software that I use, nor do I want my users to have to do it. This is not a solution to the problems at hand.

> The rest (adding methods -> you may collide with an interface which you didn't before) can probably be detected

No, they can't. From looking at your code you only get an outwards pointing import-arrow. There is no way for you to know which code actually relies on your API and in what way. You might, say, limit your guarantees to packages on godoc.org (which is indeed what I do in practice), but it's still hardly a solution to the problem.

> If you manage to limit most of your changes to "can be automatically changed / detected", you have a fair bit more freedom.

This is indeed the path I'm currently following; for every breaking change, provide an automatic fix. It still isn't an actual solution, though, just a halfway decent workaround. It especially doesn't work without https://github.com/golang/go/issues/18130 and a couple of other needed changes.

Luckily, go has immensely powerful tools to perform these kinds of rewrites (much more powerful than any other language I'm aware of) and I'm thus pretty optimistic that this will provide a good way forward soon (now that the need for gradual repair is officially recognized).

[Groxx]

Yeah... no, they're not focusing on large. Look at the vendoring hell, the weak typing / nonsense around no-generics vs oh-but-maps-are leading to error-prone switch statements, and lack of control-of-the-language. Larger than Python projects tend to support without pain, absolutely (and that's an important area), but not large. Service-units in a large system, sure, which is likely what many will use it for, but it's just not friendly to millions of lines of code and tens or hundreds of developers. Their solution to things getting out of hand or having performance problems is to divide the system, not to have a system that can handle it.

edit: oh boy, right at the top, a winner: Go's design considerations include rigorous dependency management, ...

Heck no it doesn't. It has been hacked on by the community, which has thankfully adopted things like Glide and GPS that do things properly, because it abandoned this whole area. As it did with e.g. debugging, for which their official stance is "use GDB, which doesn't really work".

[Merovius]

> the weak typing

What do you mean?

> nonsense around no-generics

What nonsense?

> error-prone switch statements

What makes them error-prone?

> lack of control-of-the-language

What do you mean?

> not large. Service-units in a large system, sure, which is likely what many will use it for, but it's just not friendly to millions of lines of code and tens or hundreds of developers.

There are go-projects like this on github. Not to mention the fact that several large companies run central parts of their infrastructure on go (I recently started working on a go-project that qualifies). I think your belief that the flaws of go disqualify it for large projects is biased on a certain, subjective perception to do things, not the objective absolute truth you are trying to make it out to be.

But even if it was correct, at best you are arguing that their efforts to focus on large software was in vain, but claiming that they don't focus on large software at all is, again, simply completely false. Please try to be constructive, here.

> Their solution to things getting out of hand or having performance problems is to divide the system, not to have a system that can handle it.

Can you give an example?

> As it did with e.g. debugging, for which their official stance is "use GDB, which doesn't really work".

I don't believe that's the official stance anymore. And IMHO, most large applications don't particularly profit from an interactive debugger anyhow (I can't just attach a debugger to a server serving thousands of requests per second and have any hope of getting useful answers). The debugging story of go is much more bound to things like "import _ net/http/pprof" and the like and systems like stackdriver.

Anyway. All of this is pretty off-topic, anyway.