In case you guys didn't know, there's multiple release party in different parts of the world: https://github.com/golang/cowg/blob/master/events/2017-08-go...
Come join if your near the area.
Go 1.9 is released
61–70 of 131 posts
Re: Go 1.9 is released
#62Earlier quoted context omitted.
In fairness, the phrase he used was "looks like". I don't think his comment was intended to suggest that he'd done rigorous and exhaustive wide-spectrum analysis of compile times and executable size, just that expectations matched the result for his project.
Thanks :) I'm no stranger to the scrutiny of Hacker News, I did 3 builds in a row and threw out the 1st one (cache), the last two were within 0.1s of each other, so I copied & pasted the latter.
So basically there's no speedup.
Re: Go 1.9 is released
#63Earlier quoted context omitted.
Errors can be anything. It's just an interface.
Except you don't get to control the specific error type returned by packages you import. So sure, you could get stack traces for your code, but not for your dependencies. It infuriates me when go proponents try and sweep bad language decisions under the rug with half-fixes. https://twitter.com/codebeeCA/status/885302657178587136
To be fair, the Go authors have always strongly promoted that you fork and maintain your dependencies. That may be a bad operational decision (outside of Google), but is technically unrelated to the language itself.
Mind you, if third party code needs debugging, you're going to have to fork it in order to apply your fixes in a timely manner anyway. Perhaps their stance is not as crazy as it may originally seem.
Re: Go 1.9 is released
#64In the release notes it says: "Mutex is now more fair." Source: https://golang.org/doc/go1.9#sync Does anyone know what that means?
You piqued my curiosity :) A comment in the source for the release notes ( https://github.com/golang/go/blob/master/doc/go1.9.html#L922 ) points to the relevant change: https://go-review.googlesource.com/c/go/+/34310 , which in turn links to this issue: https://github.com/golang/go/issues/13086
Ah, thanks for the links.
I googled a little bit and found some good info, I guess I had forgotten a little bit of the concepts of mutex fairness/unfairness. I found a very nice explanation on cs.stackexchange:
"My understanding is that most popular implementations of a mutex (e.g. std::mutex in C++) do not guarantee fairness -- that is, they do not guarantee that in instances of contention, the lock will be acquired by threads in the order that they called lock(). In fact, it is even possible (although hopefully uncommon) that in cases of high contention, some of the threads waiting to acquire the mutex might never acquire it."
With that computer science clarification, I think the comment "Mutex is now more fair" and the detailed description "Unfair wait time is now limited to 1ms" makes it a lot clearer.
Great improvement I think! It's one of those things that you don't notice until you have a bug, but it's really nice to never get that bug in the first place. =)
Re: Go 1.9 is released
#65Re: Go 1.9 is released
#66Earlier quoted context omitted.
Do native Go programs use libc?
For a few things like system DNS resolver in net package (can be switched to the pure Go version with compile-time or run-time switch) and getting user's home directory in os/user package.
To expand on this:
$ cat foo.go
package main
import (
"fmt"
)
func main() {
fmt.Println("Hello")
}
$ go build foo.go
$ file foo
foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
$ cat bar.go
package main
import (
"os/user"
"fmt"
)
func main() {
u, err := user.Current()
fmt.Println(u, err)
}
$ go build bar.go
$ file bar
bar: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not strippedRe: Go 1.9 is released
#67In case someone cares about these things, I compared the build times and the binary sizes for 1.9 vs 1.8.3 using the open source project we maintain [1]. This is on a 6-core i7-5280K: Build time with 1.8.3: real 0m7.533s user 0m36.913s sys 0m2.856s Build time with 1.9: real 0m6.830s user 0m35.082s sys 0m2.384s Binary size: 1.8.3 : 19929736 bytes 1.9 : 20004424 bytes So... looks like the multi-threaded compilation ind…
Unless you perform a proper statistical analysis it's unfair to draw a conclusion from a single run. Furthermore, when I see a second run that's faster than the first one, I immediately wonder if it's the cache being cold for the first run and warm for the second. While I have your attention, https://zedshaw.com/archive/programmers-need-to-learn-statis... is worth reading.
"Programmers Need To Learn Statistics Or I Will Kill Them All"... What an insufferable asshat.
PSA: There is no reason to behave like this and this is an incredible way to alienate a bunch of people. You either offend people directly with the murder implication or they don't take you seriously because you sound like you're throwing such an extended temper tantrum that you managed to write it all in a blog.
Re: Go 1.9 is released
#68Earlier quoted context omitted.
Except you don't get to control the specific error type returned by packages you import. So sure, you could get stack traces for your code, but not for your dependencies. It infuriates me when go proponents try and sweep bad language decisions under the rug with half-fixes. https://twitter.com/codebeeCA/status/885302657178587136
To be fair, the Go authors have always strongly promoted that you fork and maintain your dependencies. That may be a bad operational decision (outside of Google), but is technically unrelated to the language itself. Mind you, if third party code needs debugging, you're going to have to fork it in order to apply your fixes in a timely manner anyway. Perhaps their stance is not as crazy as it may originally seem.
Can you point me to a quote where Go authors have encouraged people to fork a third party library in order to insert better error handling code?
I don't want to insult anyone, but this seems like an utterly insane software engineering practice to me. It means you can't just update to the next version of that library any longer. You're taking it upon yourself to review and patch every single new version of that library. Manually.
Re: Go 1.9 is released
#69Earlier quoted context omitted.
Except you don't get to control the specific error type returned by packages you import. So sure, you could get stack traces for your code, but not for your dependencies. It infuriates me when go proponents try and sweep bad language decisions under the rug with half-fixes. https://twitter.com/codebeeCA/status/885302657178587136
To be fair, the Go authors have always strongly promoted that you fork and maintain your dependencies. That may be a bad operational decision (outside of Google), but is technically unrelated to the language itself. Mind you, if third party code needs debugging, you're going to have to fork it in order to apply your fixes in a timely manner anyway. Perhaps their stance is not as crazy as it may originally seem.
And with my professional experience, sometimes maintaining a program over a decade, I have to agree. When you are using an external library, you have to at least have a copy of the version you are using. Repositories might go away without a warning. Also, you want to go to a new version only after some review. Ideally, you don't have any local modifications - if you patch libraries, you should donate the changes back. But then, it happened that patches were rejected. In the end you are going to need a local copy/branch for several reasons.
Re: Go 1.9 is released
#70I'm wondering if we could abuse type alias to fake generics somehow? E.g.
// file tree.go
type T = YourConcreteType
type TreeNode struct {
Value T
}
// rest of tree implementation
Seems simpler to use than the unicode hack here https://www.reddit.com/r/rust/comments/5penft/parallelizing_...