I believe @bradfitz had similar ideas in the past for the http-related packages, since the need to move faster pushed the development onto the x/net repository.

I think this is a great idea and it should happen in the long run; my only worry is making the process smooth and well executed.

I also imagine @bcmills @ianthehat @rsc will have some strong opinions here.

Another feature in this area is to let the runtime and stdlib support third-party compilers implementing other languages, as with Kotlin & Clojure in the Java ecosystem.

As someone who works on custom Go compilers and special environments like embedded software and kernel-level software, I fully support this.

For example, the platform- and compiler-independent bits of the standard library could be shipped as a new Go module while packages that are closely related to the compiler/runtime could be bundled with the compiler.

Partially related discussion in #30241 and golang-dev thread, which focus on the creation of two special modules std and cmd in 1.13.

As an idea, I support this. But as always the details are complex. To make this happen will require more than expressing a desire: it will require a plan for an end goal and specific steps to reach that goal.

In the abstract, separating these pieces sounds like a good idea, but the concrete details matter and their costs may outweigh the benefit. What this proposal needs specifically is concrete detail about exactly what to do to achieve this idea, what the implications would be for other parts, and so on. This separation would be a major change so there would be a lot to consider.

For example, the first concern I would have is how this interacts with the release process and making sure that Go releases remain well tested. If the runtime/compiler and standard library have to be released separately then there is twice as much testing, more combinations to worry about, and so on. That's an example of a cost to doing this. There are more.

If the motivation is TinyGo and GopherJS, then perhaps a narrower focus would be equally helpful. If there are specific packages that could be made easier to drop into other systems (for example by moving code between files and/or adding appropriate build tags), that is much simpler with lower cost.

It's hard to believe the runtime package in particular would ever be separated from the compiler, but maybe the rest could.

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

Probably should be re-opened and tagged NeedsInvestigation instead of WaitingForInfo.
@bcmills @rsc

I think leaving this closed is correct for now. We don't need issues open for abstract ideas. Those kinds of issues just sit around untouched for years without adding any value to the project.

Hmmm, it's not really an abstract idea. It's something that's really desirable to get thought through then implemented. Can't really do that if it's been closed. 😦

Experience shows pretty clearly that the issue tracker is not a good place to think through a complex subject. The biggest problem is the lack of threading, and a secondary problem is the fact that when there are many comments GitHub hides the ones in the middle. Without a specific focus we see that conversations on the issue tracker spin off and become impossible to track.

I agree there is no concrete proposal yet. I'll work on one when I get to that again...
But to reply to a few specific concerns:

If the runtime/compiler and standard library have to be released separately then there is twice as much testing, more combinations to worry about, and so on.

This is not my intention. Basically everything would mostly stay as it is. In particular:

It's hard to believe the runtime package in particular would ever be separated from the compiler, but maybe the rest could.

No, that's not the intention. There are basically 3 components here, (over)simplifying a bit:

• The compiler.
• The runtime. With this I mean the packages runtime, reflect, sync, and various internal packages used by the net and os packages related to scheduling. Also: the implementation of time.Sleep that actually lives in the runtime package.
• The standard library, which is all importable packages under the src directory in the source tree excluding the runtime packages.

My proposal would be to define a clearly defined (and perhaps versioned) API between the runtime and the stdlib. The compiler<->runtime interaction would mostly remain an implementation detail, just as it is now. This allows compilers to provide their own runtime implementation while reusing the (rest of) the standard library.

Probably the most difficult part here is namespacing. For example, while the net package is closely coupled with the runtime, the net/http package is not. Same with os and os/exec (I think).

I hope to write down a more formal proposal in the future, but hope that this makes it all a bit more clear what this proposal is and is not about.