Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.9 is released

blog.golang.org

Post reply on HN
Print view View original

81–90 of 131 posts

Re: Go 1.9 is released

#81

Post by riobard »

ptman wrote: post #76
riobard wrote: post #70

I'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 Then you can just copy the file and replace YourConcreteType at the top and voila! Seems simpler to use than the unicode hack here https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

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.

Re: Go 1.9 is released

#82

Post by pvg »

alphaalpha101 wrote: post #50
pvg wrote: post #40

Earlier quoted context omitted.

They're discouraged from complaining about downvoting.

It was not a complaint, it was a question , just like my top-level comment. Was that interpreted as a complaint as well? Is that the problem?

It sounded like complaining but either way, take a look at these.

https://news.ycombinator.com/newsguidelines.html

"Please don't comment about the voting on comments. It never does any good, and it makes boring reading."

Re: Go 1.9 is released

#83

Post by stewbrew »

riobard wrote: post #70

I'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 Then you can just copy the file and replace YourConcreteType at the top and voila! Seems simpler to use than the unicode hack here https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

Now make that a compile time thing that happens on imports and that doesn't generate temporary source files and whoop you have modules with generics. Oops, I forgot that there are some unsolvable obstacles to be resolved.

Re: Go 1.9 is released

#84

Post by pjmlp »

arghwhat wrote: post #73
agnivade wrote: post #53

Earlier quoted context omitted.

> Aren't go programs statically linked? Not by default. You have to set CGO_ENABLED=0 to statically link libc.

Well, Go code is statically linked, but the runtime may try to dynamically load libc for DNS resolving. Use of cgo of course drastically change everything.

By default, nowadays the toolchain also supports generating dynamic libraries.

Re: Go 1.9 is released

#85

Post by jimjimjim »

stouset wrote: post #47
cpuguy83 wrote: post #34

Earlier 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

it infuriates me when third-party stuff in other languages throws exceptions and you end up needing to check everything anyway.

exceptions are a curse.

Re: Go 1.9 is released

#86

Post by pron »

baq wrote: post #77
hueving wrote: 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.

Or, you can be not offended and still criticise someone for being an asshat.

Re: Go 1.9 is released

#87

Post by noselasd »

amenghra wrote: post #29
old-gregg wrote: post #22

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

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 crowd and I do hope the answer is not "go learn statistics".

Re: Go 1.9 is released

#88

Post by chillydawg »

noselasd wrote: post #87
amenghra wrote: post #29

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…

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're all over the place do "lots" and only stop once the mean stabilises. There are specific methods to define "lots" and "a few" but it's usually obvious for large effects and you don't need to worry too much about it.

If you're trying to prove that you've made a 0.1 improvement on an underlying process that is normally distributed with a stddev of, like 2, then you're going to have to run it a lot and do some maths to show when to stop and accept the result.

Re: Go 1.9 is released

#89

Post by junke »

jimjimjim wrote: post #85
stouset wrote: post #47

Earlier 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

it infuriates me when third-party stuff in other languages throws exceptions and you end up needing to check everything anyway. exceptions are a curse.

Errors are part of the third-party stuff's API. Don't be surprised if you have to handle them.

Re: Go 1.9 is released

#90

Post by fnord123 »

chillydawg wrote: post #88
noselasd wrote: post #87

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

I want measurements with filesystem cache because I'm interested in estimating the speed of the compile-test-edit cycle. If you want to estimate the impact on emerge then you'll want no filesystem cache.

It's all about measuring based on what you intend to use the measurements for.

Post reply on HN