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

41–50 of 131 posts

Re: Go 1.9 is released

#41

Post by pvg »

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…

Aren't go programs statically linked? The change in binary size might be completely unrelated to changes in the compiler.

Re: Go 1.9 is released

#42

Post by logicallee »

azinman2 wrote: post #27
artursapek wrote: post #6

Earlier quoted context omitted.

It could just be one map shared by many goroutines, which normally causes a panic: fatal error: concurrent map writes

Standard practice is to use a mutex to guard against concurrent usage.

also necessary for reads?

Also, do you have any good references to proper best practices around concurrent and parallel programming? (in Go.) Like just basic things. Code I can copy and paste without it having obscure race conditions because that use of mutex is absolutely correct, and something that lets me understand the limitations. I feel like it is very easy to do things "wrong" or not notice some edge cases. In C++ I didn't only ever coded single-threaded for this reason. Too many gotchas. Any help would be appreciated.

Re: Go 1.9 is released

#43

Post by andrewjw »

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

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…

"type safe" has come to mean "statically type safe" over time in common conversation. You were downvoted because this intended usage was clear to the people who downvoted you and their perception of your comment was that it provided no value, e.g. was a nitpick.

I would note that the Wikipedia page does not take as strong a position as you seem to imply, reading:

> In the context of static (compile-time) type systems, type safety usually involves (among other things) a guarantee that the eventual value of any expression will be a legitimate member of that expression's static type. The precise requirement is more subtle than this — see, for example, subtype and polymorphism for complications.

Since golang is statically typed, type safety is generally understood to mean static type safety.

Re: Go 1.9 is released

#44

Post by carbocation »

logicallee wrote: post #42
azinman2 wrote: post #27

Earlier quoted context omitted.

Standard practice is to use a mutex to guard against concurrent usage.

also necessary for reads? Also, do you have any good references to proper best practices around concurrent and parallel programming? (in Go.) Like just basic things. Code I can copy and paste without it having obscure race conditions because that use of mutex is absolutely correct, and something that lets me understand the limitations. I feel like it is very easy to do things "wrong" or not notice some edge cases. In…

Necessary for reads unless no additional writing will be done. If you initialize/write into a map and then later have concurrent reads from it, the program will run. If you try to write in the midst of this, it will crash.

Re: Go 1.9 is released

#45

Post by fish_fan »

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

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…

Well, non-type safety isn't really worth discussing. The big differentiators these days are: does it fail at compile time or run time? This is emphatically the latter category.

Re: Go 1.9 is released

#47

Post by stouset »

cpuguy83 wrote: post #34
throw4625 wrote: post #33

Earlier quoted context omitted.

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.

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

Re: Go 1.9 is released

#48

Post by deckarep »

squiguy7 wrote: post #11
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'?

This lightning talk gives some great information on use cases for the new sync.Map: https://youtu.be/C1EtfDnsdDs

Wow great find!

Re: Go 1.9 is released

#50

Post by alphaalpha101 »

pvg wrote: post #40
alphaalpha101 wrote: post #38

Earlier quoted context omitted.

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.

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?

Post reply on HN