On Mon, Jan 27, 2020 at 1:27 PM Robert Engels <reng...@ix.netcom.com> wrote: > > Doesn’t this piggyback on making the runtime a shared library so it can be > updated without application recompile?
I guess I'm not sure what you mean. That already works today, for people who choose to use it. It seems independent of how we manage Go releases. Ian > > 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/CAOyqgcU66aAXq6d%3DwAmNLHX3G2V3FsFUsGiMRt1dg%3DpuQQiETA%40mail.gmail.com.
