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

31–40 of 131 posts

Re: Go 1.9 is released

#31

Post by ryeguy »

kjksf wrote: post #28
cristaloleg wrote: post #9

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…

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.

Re: Go 1.9 is released

#33

Post by throw4625 »

azinman2 wrote: post #14
alpb wrote: post #4

t.Helper() is certainly going to be very useful. I often implement functions like: func testServer(t *testing.T, port int) { ...do stuff... if err != nil { t.Fatalf("failed to start server: %+v", err) } } similarly you can have func assertMapEquals(t *testing.T, a, b map[string]int) It lets you hide such helper methods from the test failure's stack trace (where t.Fatal is actually called), making test errors more rea…

Yes indeed this is totally awesome. It’s a problem that occurs on any platform, and not only for testing. I often see this problem with logging as well, where some validation/helper function logs an error separate from the context it occurred in, potentially making it hard to trace without a stacktrace logged as well.

This is the biggest problem with Go errors and one of my biggest gripes with the language. Exceptions have stacktraces that give you context about where the error originated. Go errors don't have this and it costs me a lot of time debugging things.https://godoc.org/github.com/pkg/errors helps, but it's still more of a pain than it should be.

Re: Go 1.9 is released

#34

Post by cpuguy83 »

throw4625 wrote: post #33
azinman2 wrote: post #14

Earlier quoted context omitted.

Yes indeed this is totally awesome. It’s a problem that occurs on any platform, and not only for testing. I often see this problem with logging as well, where some validation/helper function logs an error separate from the context it occurred in, potentially making it hard to trace without a stacktrace logged as well.

This is the biggest problem with Go errors and one of my biggest gripes with the language. Exceptions have stacktraces that give you context about where the error originated. Go errors don't have this and it costs me a lot of time debugging things. https://godoc.org/github.com/pkg/errors helps, but it's still more of a pain than it should be.

Errors can be anything. It's just an interface.

Re: Go 1.9 is released

#36

Post by kjksf »

ryeguy wrote: post #31
kjksf wrote: 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.

According to whom? Certainly not according to wikipedia.

Given that it's a pretty big distinction I would think it's on the speaker to be un-ambiguous and say "it's not statically type safe" vs. ambiguous "type safe".

I've certainly seen my share of people claiming that "interface{} is just like void * in C" when they speak about Go's (lack of) type safety.

I also don't see how insisting on accurate and un-ambiguous terminology ticks people off so much to downvote. I imagine they think I said something much more incorrect than I did.

Re: Go 1.9 is released

#37

Post by ovao »

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.

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.

Re: Go 1.9 is released

#38

Post by alphaalpha101 »

alphaalpha101 wrote: post #3

So this new concurrent map? Am I right in understanding it's designed for cases where you have a map shared between goroutines but where each goroutine essentially owns some subset of the keys in the map? So basically it's designed for cases like 'I have N goroutines and each one owns 1/N keys'?

I really, really don't understand why this would get downvoted. Are people not allowed to ask questions now?

Re: Go 1.9 is released

#39

Post by old-gregg »

ovao wrote: post #37
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.

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.

Re: Go 1.9 is released

#40

Post by pvg »

alphaalpha101 wrote: post #38
alphaalpha101 wrote: post #3

So this new concurrent map? Am I right in understanding it's designed for cases where you have a map shared between goroutines but where each goroutine essentially owns some subset of the keys in the map? So basically it's designed for cases like 'I have N goroutines and each one owns 1/N keys'?

I really, really don't understand why this would get downvoted. Are people not allowed to ask questions now?

They're discouraged from complaining about downvoting.
Post reply on HN