Doesn’t this piggyback on making the runtime a shared library so it can be updated without application recompile?
> On Jan 27, 2020, at 2:24 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Mon, Jan 27, 2020 at 7:02 AM 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: >> >> The original message mentions size. The given list is 25MB/337MB >> uncompressed or 7MB/115MB compressed. So in terms of saved space, we are >> talking ~6%. It's not nothing, but it's also not a lot. Especially as you'll >> most likely need to download them right after anyway. >> >> You also mentions splitting up the issue tracker. But note, that even though >> the various x-repos are already separate repositories, they still use the >> same issue-tracker. Clearly, having a unified issue tracker is perceived as >> a *benefit* to the Go team, not a detriment. >> >> It might indeed be worth versioning the stdlib as modules at some point. I >> know that was discussed as part of the question of what "Go 2" means. Having >> the ability to bump major versions of the stdlib would enable to overhaul >> APIs at some point in the future. But note that the Go 1 stability promise >> stays in place, so again, neither in terms of size, nor in terms of >> splitting management, this would provide any benefits. Programs using Go v1 >> stdlib packages will likely continue to exist into the far future, so even >> *if* there's at some point a v2 of the stdlib, v1 will still need to be >> shipped and supported (though likely the v1 API would wrap v2 packages, so >> the actual size increase would be moderate). But all of this is still far in >> the future, AFAICT. > > > I see two different things to consider. One is the possibility of > splitting the release into separate downloadable files. That by > itself seems simple enough, and we could do it if it seems useful. > But as Axel says it doesn't seem all that useful. It seems like it > would make downloading a release more complex for 99% of people for > the benefit of 1% of people. That's not an impossible tradeoff but it > needs to really be a big help for the 1%. I don't see the benefit > myself (but admittedly I have a fast Internet connection anyhow). > > The more interesting thing to consider is that if we split the release > like that, people will naturally start mixing and matching different > versions, either on purpose or by accident. That could be useful in > some ways, but it is also much harder to support. Considering how > much trouble we have making a single unified release, it's not obvious > to me that the Go team has the bandwidth to handle separate release > cycles that need to work together. > > Ian > > > >>> On Mon, Jan 27, 2020 at 3:31 PM Volker Dobler <dr.volker.dob...@gmail.com> >>> wrote: >>> >>> On Monday, 27 January 2020 12:27:35 UTC+1, changkun wrote: >>>> >>>> Dear golang-nuts, >>>> >>>> As https://github.com/golang/go/issues/27151, >>>> https://github.com/golang/go/issues/6853 and many relevant issues >>>> discussed, Go download is huge. >>> >>> >>> Neither of these issues benefits from splitting the stdlib from the >>> compiler and/or the "runtime" (whatever you mean by that). >>> Separating the compiler from its stdlib seems strange at least >>> and does not help, neither to increase development speed nor >>> to increase convenience. >>> >>> V. >>> >>>> >>>> >>>> The Go download contains everything in the main repo. Since Go modules are >>>> now a success, is it considered to separate all runtime irrelevant >>>> (meaning, no need runtime support to implement, e.g. net poller need >>>> runtime support because there is a scheduler) libraries out of the main >>>> repo? >>>> >>>> For instance, the following packages can be separated to be stored in a >>>> different repository, called std module: >>>> >>>> std/archive >>>> std/bufio >>>> std/bytes >>>> std/compress >>>> std/container >>>> std/context >>>> std/crypto >>>> std/database >>>> std/encoding >>>> std/errors >>>> std/expvar >>>> std/flag >>>> std/go >>>> std/hash >>>> std/html >>>> std/image >>>> std/index >>>> std/io >>>> std/log >>>> std/math >>>> std/mime >>>> std/path >>>> std/plugin >>>> std/regexp >>>> std/sort >>>> std/strconv >>>> std/strings >>>> std/syscall >>>> std/testdata >>>> std/testing >>>> std/text >>>> std/unicode >>>> >>>> Say we have a separate repository called golang/std, import these packages >>>> can have the same import path, instead of "std/io", go modules can >>>> overwrite the import path exactly like what it did for >>>> "github.com/user/mod/v2", set the imported std modules in go.mod file, >>>> import as "io" directly. >>>> >>>> Thanks for reading. >>>> Changkun >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to golang-nuts+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/e1f86127-bdcb-411b-b50a-991845fc3e90%40googlegroups.com. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHmJi0vOkG39CuTXrqAY0uO-x9aL12desRXE_hsmBUoVw%40mail.gmail.com. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVuXaBeJUwcbw7cLbpMR_GHxRgtggB%2Bi9MWRAQFzrxYeg%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/A0DA279A-4167-4D22-A940-400742152C1B%40ix.netcom.com.
