Live data from Hacker News

Go 1.9 is released

blog.golang.org

91–100 of 131 posts

Re: Go 1.9 is released

#91
post #77
post #67

Earlier quoted context omitted.

"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.

or you can stop being offended by words put out on the internet by strangers... which is what i always recommended to basically everyone.

I'm not offended. I'm just not going to waste my time reading an article by someone behaving like a child.

Re: Go 1.9 is released

#92
post #81
post #76

Earlier quoted context omitted.

What if I want both TreeNode and TreeNode ?

Easy. You copy the original file twice and put them in two different sub directories, say treef64 and treerune.

Not copy – symbolic link. Then there’s just the one source file.

Not that I would want this in my project. But as a hack, it’s even better than it first sounds.

Re: Go 1.9 is released

#93
post #28

Please remember that sync.Map isn't type safe and is more optimised for reads.

interface{} and therefore sync.Map is type safe. https://en.wikipedia.org/wiki/Type_safety > Type enforcement can be static, catching potential errors at compile time, or dynamic, associating type information with values at run-time and consulting them as needed to detect imminent errors, or a combination of both. interface{} is type-checked at runtime. It's type-safe because because you can't e.g. fish out an intege…

This is incorrect. What you're referring to is "memory safety".

Re: Go 1.9 is released

#94

Earlier quoted context omitted.

So honest question from a non-statistician, how, concretely, should I go about doing this particular analyzis of compile time for one project ? How many times should I run the build for each of the 2 compilers and what should I do with the result so I could; 1. Draw a conclusion 2. Come up with fair numbers of how they compare ? I would hope someone could tech this hopefully simple and very concrete thing to the HN c…

You need to first create a clean slate each time for running the experiment: no cache, no FILESYSTEM cache etc. Maybe a tonne of single use docker images? Even then filesystem caches will mess you up a little. Beyond that, you need to run the same build "several" times to see what the variance is. Without getting specific, if the builds are within a couple percent of each other, do "a few" and take the mean. If they'…

If the measurements are all over the place, why not take the fastest? The average is no good, because it'll be influenced by the times it wasn't running as fast as possible.

I don't myself lose much sleep over worrying about the times it runs faster than possible.

Re: Go 1.9 is released

#95

Earlier quoted context omitted.

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 librar…

See: Any discussion related to go get and its design motivations.

Even vendoring, which was added to the tooling later, is built on the idea of keeping your own fork. It just simplifies the forking process for people who do not work like Google does, where each fork is shared company-wide.

Re: Go 1.9 is released

#96
post #61

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.

None in London :(

Re: Go 1.9 is released

#97

Earlier quoted context omitted.

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.

So honest question from a non-statistician, how, concretely, should I go about doing this particular analyzis of compile time for one project ? How many times should I run the build for each of the 2 compilers and what should I do with the result so I could; 1. Draw a conclusion 2. Come up with fair numbers of how they compare ? I would hope someone could tech this hopefully simple and very concrete thing to the HN c…

There are people who have thought about this, e.g., http://onlinelibrary.wiley.com/doi/10.1002/cpe.2939/full

Personally I think it's a better idea to instrument your programs and count the number of memory (block) accesses or something. That metric might actually be useful to a reader a few years in the future. The fact that your program was running faster on a modern x86 processor from the year 2010 tells me nothing about how it would perform today, unless the difference was so large that you never needed statistical testing in the first place...

edit: I'm not sure if this paper is accessible to everyone, so here is an alternate link https://hal.inria.fr/inria-00443839v1/document

Re: Go 1.9 is released

#98
post #58

In 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

Check the comment here on Mutex faireness: https://go-review.googlesource.com/c/go/+/34310/8/src/sync/m...

> Mutex fairness.

> Mutex can be in 2 modes of operations: normal and starvation.

> In normal mode waiters are queued in FIFO order, but a woken up waiter

> does not own the mutex and competes with new arriving goroutines over

> the ownership. New arriving goroutines have an advantage -- they are

> already running on CPU and there can be lots of them, so a woken up

> waiter has good chances of losing. In such case it is queued at front

> of the wait queue. If a waiter fails to acquire the mutex for more than 1ms,

> it switches mutex to the starvation mode.

> In starvation mode ownership of the mutex is directly handed off from

> the unlocking goroutine to the waiter at the front of the queue.

> New arriving goroutines don't try to acquire the mutex even if it appears

> to be unlocked, and don't try to spin. Instead they queue themselves at

> the tail of the wait queue.

> If a waiter receives ownership of the mutex and sees that either

> (1) it is the last waiter in the queue, or (2) it waited for less than 1 ms,

> it switches mutex back to normal operation mode.

> Normal mode has considerably better performance as a goroutine can acquire

> a mutex several times in a row even if there are blocked waiters.

> Starvation mode is important to prevent pathological cases of tail latency.

Re: Go 1.9 is released

#99
post #31
post #28

Earlier quoted context omitted.

interface{} and therefore sync.Map is type safe. https://en.wikipedia.org/wiki/Type_safety > Type enforcement can be static, catching potential errors at compile time, or dynamic, associating type information with values at run-time and consulting them as needed to detect imminent errors, or a combination of both. interface{} is type-checked at runtime. It's type-safe because because you can't e.g. fish out an intege…

When "type safe" is mentioned without qualification, it almost always refers to static type safety. This is one of those times. So no, the sync.Map container is not typesafe like a regular map is.

Can you explain what you mean by static type safety?

Re: Go 1.9 is released

#100
post #99
post #31

Earlier quoted context omitted.

When "type safe" is mentioned without qualification, it almost always refers to static type safety. This is one of those times. So no, the sync.Map container is not typesafe like a regular map is.

Can you explain what you mean by static type safety?

"Static type safety" will generally mean type safety established at compile time. In this context, "static" tends to mean "compile time" and "dynamic" tends to mean "runtime".

For example, one might say "static code analysis" to mean analyzing code without running it, such as during a phase during compilation. In contrast, "dynamic code analysis" tends to mean actually running the code and making decisions based on what happens at runtime, such as in JIT (https://en.wikipedia.org/wiki/Just-in-time_compilation) techniques that identify hotspots.

Post reply on HN