So, go fails to work on IPv6 environments, but they've gone through the effort to actually implement http2? Looks like their priorities are all messed up. :-/
What are you talking about? The net package does support ipv6[0].
Also, while ipv6 is important, let's keep in mind that many hosting providers (including Amazon) still don't provide IPv6, and have no timeline for it either.
HTTP2 is at the application level, so it is useful immediately, without any change to existing infrastructure.
> Also, while ipv6 is important, let's keep in mind that many hosting providers (including Amazon) still don't provide IPv6, and have no timeline for it either.
There are transitional techniques, like NAT64 to connect to those hosts. Keep in mind that some ISPs only offer native IPv6, so lack of proper IPv6 support means go-apps become unusable.
There's IPv6 support, but things like `conn, err := net.Dial("tcp", "google.com:80")` fail on IPv6-only hosts, because only an IPv4 connection is attempted.
(It does not seem weird to me that they'd prioritize functionality that everyone with a modern browser will be able to use versus functionality that quite possibly won't be useful to most Internet users ever.)
> versus functionality that quite possibly won't be useful to most Internet users ever.)
You don't think that IPv6 is ever going to gain widespread adoption?
Given how much of the US uses Comcast as their residential ISP alone, and how aggressively Comcast has been rolling out IPv6, I think we're near a tipping point[0].
Enterprise/business use will take much longer, but that's to be expected, as rollout for residential use has far fewer potential problems.
Nope, I don't. (I'm less certain of this than I am about DNSSEC, but in the same ballpark on both).
I think this is, for what it's worth, a good thing. IP belongs to the telcos. The failure of IPv6 adoption (and it's been failing for a long time) is forcing us into building overlays on top of ephemeral/translated IPv4 endpoints, which has the effect of pushing responsibilities back towards the endpoints and away from opaque middleboxes.
This may be an interesting contrarian position to argue, but come on. The NAT situation takes us toward end-to-end and away from middleboxes? In real life it's more likely for communities and systems to bow than rebound in response to strong chilling effects.
This isn't a contrarian position. The only VC-backed startup I founded had this as a premise. I don't just think it's the right architectural plan for the Internet. I think it's what's going to happen.
Indeed. The number of use users with no native IPv4 are probably a lot less than dual-stacked users, but inevitably, the amount of IPv6-only users will continue growing, given the current trend.
Lack of IPv6 support means that some people have no network capabilities when using go-based apps (eg: a critical, fatal bug).
https is just a an enhancement.
The thread you pointed to doesn't back up the broad statement you're trying to make about Golang, and, like most of the world, this is an issue I don't care about, so I disagree with your prioritization.
People on CLNP-only networks also have problems with Golang, despite the fact that Unix kernels do provide CLNP sockets.
However, CLNP is not deployed by any major ISP. It's not gradually replacing IPv4 either.
A small percentage of users around the world have IPv6-only (+ some transition mechanism) connections and have no issues using the general internet. This number is continuosly growing, and will continue growing.
This issue will affect you inevitably, so I think it's extremely shortsighted to not-care about it.
Supporting IPv6 and "working normally on IPv6 environemnts" are different things. As an end-user, go-apps don't work over IPv6 unless they're hardcoded to use only that:
net.Dial() really is terrible, but it's fairly easy to work around. Instead of passing a hostname to net.Dial(), you can call net.LookupHost(...) and iterate over the resulting IP addresses.
It sounds that it adds too much burden to developers to simply communicate to some host over HTTP. It sounds pretty hard to convince every single developer out there to replace net.Dial with that.
30 comments
[ 4.6 ms ] story [ 69.9 ms ] threadI wonder if HTTP/2 will change the way we develop websites now that it's cheaper to load resources?
Neither will Dart, btw.
https://twitter.com/digitalocean/status/460844653424541696
CoreOS seems pretty useful, too.
Hmm.. Yeah, Go definitely isn't going to happen. /s
Also, while ipv6 is important, let's keep in mind that many hosting providers (including Amazon) still don't provide IPv6, and have no timeline for it either.
HTTP2 is at the application level, so it is useful immediately, without any change to existing infrastructure.
[0] http://golang.org/pkg/net/
There are transitional techniques, like NAT64 to connect to those hosts. Keep in mind that some ISPs only offer native IPv6, so lack of proper IPv6 support means go-apps become unusable.
There's IPv6 support, but things like `conn, err := net.Dial("tcp", "google.com:80")` fail on IPv6-only hosts, because only an IPv4 connection is attempted.
(It does not seem weird to me that they'd prioritize functionality that everyone with a modern browser will be able to use versus functionality that quite possibly won't be useful to most Internet users ever.)
You don't think that IPv6 is ever going to gain widespread adoption?
Given how much of the US uses Comcast as their residential ISP alone, and how aggressively Comcast has been rolling out IPv6, I think we're near a tipping point[0].
Enterprise/business use will take much longer, but that's to be expected, as rollout for residential use has far fewer potential problems.
(For the record, I did not downvote you).
[0] http://www.google.com/intl/en/ipv6/statistics.html
I think this is, for what it's worth, a good thing. IP belongs to the telcos. The failure of IPv6 adoption (and it's been failing for a long time) is forcing us into building overlays on top of ephemeral/translated IPv4 endpoints, which has the effect of pushing responsibilities back towards the endpoints and away from opaque middleboxes.
Lack of IPv6 support means that some people have no network capabilities when using go-based apps (eg: a critical, fatal bug). https is just a an enhancement.
critical bugs come before enhacements.
People on CLNP-only networks also have problems with Golang, despite the fact that Unix kernels do provide CLNP sockets.
A small percentage of users around the world have IPv6-only (+ some transition mechanism) connections and have no issues using the general internet. This number is continuosly growing, and will continue growing.
This issue will affect you inevitably, so I think it's extremely shortsighted to not-care about it.
https://code.google.com/p/go/issues/detail?id=8124