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. 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 > <https://groups.google.com/d/msgid/golang-nuts/e1f86127-bdcb-411b-b50a-991845fc3e90%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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.