Go 1.7.1 Released
golang.orgThe 14 issues tagged 1.7.1:
net: retry DNS lookups before failure?
io: endless loop in MultiReader in Go 1.7
path/filepath: EvalSymlinks is broken for relative paths on Windows
net/http/httputil: Proxy terminates HTTP/2 stream before reading response body.
hash/crc32: wrong output for unaligned input on s390x
cmd/compile: incorrect assignment to uint64 via pointer converted to *uint16 (new in 1.7)
doc: deprecation message for Transport.CancelRequest is not correct Documentation
compress/zlib: Writer appears to ignore underlying writer errors at times.
net: NATs client can't connect to server when client built with go1.7: "dial tcp: no suitable address found"
doc: go1.7 release notes include typo for TLSConfig.NextProtos Documentation
reflect: ChanOf makes "han" types instead of "chan" types
x/mobile: Binding go mobile framework on iOS 9 with golang1.7rc6 crash when call debug.FreeOSMemory()
net/http: nil pointer dereference in closeConnIfStillIdle
website: retina favicon Suggested> nil pointer dereference in closeConnIfStillIdle
What happens here? Does Go suffer from boundary access issues that C has? You know, in Rust, you don't have to worry about that, but is it the same for GO?
Go has null pointers, unlike Rust. Dereferencing a null reference type generally panics, but there are some random exceptions (e.g. indexing a nil map returns a zero value of the appropriate type).
I've run into intermittent issues with net/http (such as the defaults for HttpClient causing application failures in production). It's just a spot you learn to pay attention to. I'm glad they're fixing some of the bugs in the code because otherwise it is an incredible part of the STD lib.
I think it would produce a runtime error and return a stack trace. Someone more qualified than me should chime in though...
Yes, like this:
package main import "io" func main() { var foo io.Closer foo.Close() } justin@t420:/tmp$ go run nil.go panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x20 pc=0x401023] goroutine 1 [running]: panic(0x463ea0, 0xc82000a140) /usr/lib/go-1.6/src/runtime/panic.go:481 +0x3e6 main.main() /tmp/nil.go:7 +0x23 exit status 2
The goroutine panics. Nil dereferences are recoverable from[1], but I'm not sure how many people expect standard library code to panic.
> Does Go suffer from boundary access issues that C has?
It has NPE (like Java or C#), though in some conditions it'll behave more like Objective-C.
We were bit by the `closeConnIfStillIdle` bug as we didn't expect the stdlib to panic like that (also something you cannot recover from, as it happens in a goroutine which you didn't create.)
I really dislike how every point release of certain projects (Go and Gitlab being prime examples) gets onto the HN frontpage. Even as someone who loves some of the projects, I find it to be a problem.
Yet I don't want to "flag" the post, because I assume there is some kind of penalty for the submitter, beyond mere downvoting. Maybe it makes sense to have some kind of option to indicate a story fits site guidelines, but really doesn't belong on the front page.
I totally agree that point releases like https://news.ycombinator.com/item?id=12362147 (ones that don't solve not a big security vulnerability) don't belong on the HN frontpage. I don't think a team member of GitLab ever submitted one and I've just shared this thread with the team and the core team to ensure that we won't do so in the future. Please let me know if there is anything else we can do to prevent noise.
I appreciate your effort.
Just to avoid any misunderstanding, I didn't mean to imply that Gitlab intentionally submits point releases or promotes them to the HN front page.
But even if that was the case, I don't think there is anything wrong per se with merely submitting to HN. Software releases can, and frequently are, on topic. And a point release that fixes a major security issue may certainly warrant the front page.
This is a complicated issue and every solution I can think of has significant, unacceptable unintended consequences. I also suspect this problem has deep roots in the upvoting behavior of certain kinds of users - it completely baffles me that this submission has over 60 upvotes.
Thanks. I understood you didn't imply that. Just wanted to make sure we're being good HN citizens :)
I like it when there's a blog post with the release, explaining a new approach to garbage collection in Go, or a new abstraction to organize processes in Elixir, etc. But this particular post appears to be just some fixes with no context so I don't see the point...
You can't control what other people find interesting.
I share this sentiment. Per their own Release page [1], this one is considered a minor version with no major features, so I don't particularly find it notable, whereas a major version would probably stimulate more discussion about the new features.
I'm not sure where the line is between 'I don't find this notable' vs. 'I find this explicitly off-topic', the latter of which would warrant a flag.
Does it bother you enough to post a message here?
It's not like someone submitted it to the front page of HN? People voted it for it to come up here... and that itself should be reason enough.
Just click "hide" then.
>I find it to be a problem.
Why?
Hey, at least it wasn't a link to a merge diff on Github!
Agreed. If it had generics or something else noteworthy, it would be news. Simply having released an 1.X.X version is not.
Heck, lately one can't even dislike Google's projects here. They have so many employees in the pr team here that you'll get moded down fast.
Just watch my post tank now for stating this.
"Please don't bait other users by inviting them to downvote you or announce that you expect to get downvoted."
Also "Please resist commenting about being downvoted. It never does any good, and it makes boring reading" which I also disagree with. Downvoting here is sometimes worthy, but often retaliatory/punishment for world-view non-conformism, and people should be called out on it.
If you're not going to spend your Karma Points(TM) on good controversy, why bother earning it?
The vote-brigade for the Linux distro company in North Carolina is the heaviest-handed.