Go 1.4 is almost done; we just need to soak the new release candidate and, if it's OK, push the button. Once again it is time to start thinking about the next release, 1.5, which is scheduled for launch in 6 months.
What will be in 1.5?
The biggest visible change will be that repository is stored in Git, not Mercurial, but that has minimal bearing on the contents of the repository.
Regarding the source itself, a few major changes are planned:
First, the garbage collector in 1.5 will be fully concurrent, with minimal pauses. This work is well underway, and is described here.
Second, the compiler, assembler, linker, and runtime for 1.5 will be entirely in Go. some of this work is done already, some will be automated, some will be done by hand, but the goal is to eliminate C from the source tree so that—except for programs that use cgo—no C compiler is necessary to build or use Go. This was proposed a while back, but is finally happening.
Finally, new ports will include 64-bit Power PC, more complete support for Android, and possibly 64-bit ARM.
And to repeat what was said last time:
Once the 1.4 release is done, we'll be open to new CLs but want to concentrate on these fundamental changes, even scheduling them so the code can move gracefully without introducing merge conflicts and other complexities. If anyone else has other wide-ranging, core work like this that would make sense for 1.5, please say so now so it can be scheduled as well.
Over the next few weeks we'll work with you to sketch out the large-scale priorities for 1.5 and pencil in the sequence of changes to satisfy them.
Please remember that the open source community is vital to the Go ecosystem. We can't thank you enough for your contributions.
-rob, for the Go team
Great! I Still hope that golang provides an official GUI package!
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Finally, new ports will include 64-bit Power PC, more complete support for Android, and possibly 64-bit ARM.
Go 1.4 is almost done; we just need to soak the new release candidate and, if it's OK, push the button. Once again it is time to start thinking about the next release, 1.5, which is scheduled for launch in 6 months.
What will be in 1.5?
The biggest visible change will be that repository is stored in Git, not Mercurial, but that has minimal bearing on the contents of the repository.
Or use the native resolver on Linux if the resolve.conf is of the normal boring variety as it is almost everywhere?
That is, only fall back to libc if the host config suggests we need to.
On Thu, Dec 4, 2014 at 9:17 AM, Brad Fitzpatrick <brad...@golang.org> wrote:
>
> Or use the native resolver on Linux if the resolve.conf is of the normal
> boring variety as it is almost everywhere?
Definitely a possibility but note that we would need to check
/etc/nsswitch.conf also.
> If you buy that argument, I propose that we instead provide an easier
> fallback for experts. Perhaps Yet Another Environment Variable to
> prefer the Go resolver.
Nah, we already have the -tag netgo workaround. I don't want to see
another environment variable.
I'm not interested in adding another configuration variable.
Go works well with a sensible default, I just want to change that default for Linux.
--
Second, the compiler, assembler, linker, and runtime for 1.5 will be entirely in Go.
Thanks for your reply Russ.
I was wrong to suggest that linux should be treated differently than
other OSs. This was motivated by the fact that linux appears to be the
most affected by this issue, but I appreciate that other *BSD's may
have their own, unknown, faults.
I'm not keen on making a program (using the net package) change its
behaviour based on the contents of /etc/nssswitch.conf when it is
moved from machine to machine, especially as the nssswitch.conf may
not be under the control of the programmer who is deploying their go
application.
Sure, you could argue that dev, test, stage and prod environments
should be identical, but this would still be a nasty gotcha if dns
resolution behaved differently between machines.
As a counter proposal, what about changing all the unix platforms,
*except* OSX, to use the go dns resolver? Again the option to enable
the cgo resolver would be via build tag.
Go 1.4 is almost done; we just need to soak the new release candidate and, if it's OK, push the button. Once again it is time to start thinking about the next release, 1.5, which is scheduled for launch in 6 months.
What will be in 1.5?
The biggest visible change will be that repository is stored in Git, not Mercurial, but that has minimal bearing on the contents of the repository.
Regarding the source itself, a few major changes are planned:
First, the garbage collector in 1.5 will be fully concurrent, with minimal pauses. This work is well underway, and is described here.
Second, the compiler, assembler, linker, and runtime for 1.5 will be entirely in Go. some of this work is done already, some will be automated, some will be done by hand, but the goal is to eliminate C from the source tree so that—except for programs that use cgo—no C compiler is necessary to build or use Go. This was proposed a while back, but is finally happening.
Finally, new ports will include 64-bit Power PC, more complete support for Android, and possibly 64-bit ARM.
And to repeat what was said last time:
Once the 1.4 release is done, we'll be open to new CLs but want to concentrate on these fundamental changes, even scheduling them so the code can move gracefully without introducing merge conflicts and other complexities. If anyone else has other wide-ranging, core work like this that would make sense for 1.5, please say so now so it can be scheduled as well.
Over the next few weeks we'll work with you to sketch out the large-scale priorities for 1.5 and pencil in the sequence of changes to satisfy them.
Please remember that the open source community is vital to the Go ecosystem. We can't thank you enough for your contributions.
-rob, for the Go team
Proposal:
I would like to raise the suggestion of switching to the native Go
based DNS resolver in the net package for GOOS=linux only.
History:
https://code.google.com/p/go/source/detail?r=cc0f39d02e93
This commit on 20 April 2011 introduced a cgo based resolver and made
it the default, replacing the existing Go based dns resolver in the
net package.
The justifications for this change was to resolve unpleasant
interactions with the OSX firewall dialog boxes if the libc dns
resolver was not used. Some other minor justifications for this
change, possibly by me, were access to things like avaihis .local
domain on linux.
Outcome:
For linux, which this proposal is only concerned with, the results
have been problematic. Because of various latent bugs and limitations
in libc in current and older linux distros, Go users on linux have
found that dns resolution when building crawlers, or proxies, to name
two examples, remains problematic.
I believe that the use case of Go programmers writing crawlers and
other network intensive clients is valid, and in fact something Go
should excel at, and the continuing issues with libc's dns resolver on
linux spoils that promise.
I have not provided details of the issues raised over the years in the
issues tracker, irc, or mailing list, but if you care about this
proposal, you've probably got a passing familiarity with the problem.
I can find references and issues if it'll help.
Proposal:
For Go 1.5, for GOOS=linux only, I propose that we change the net
package to default to the pure Go dns resolver. An option for building
the net package _with_ libc's dns resolver should also be provided.
Thank you for your time.
Dave
On Thu, Dec 4, 2014 at 9:17 AM, Brad Fitzpatrick <brad...@golang.org> wrote:
>
> Or use the native resolver on Linux if the resolve.conf is of the normal
> boring variety as it is almost everywhere?
Definitely a possibility but note that we would need to check
/etc/nsswitch.conf also.