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.
