Introducing the Go Race Detector | Hacker News Reader

Introducing the Go Race Detector

blog.golang.org

137 pointsenneff40 comments

"it is only as good as your tests; you must make sure they thoroughly exercise the concurrent properties of your code so that the race detector can do its job." <-- it's not a magical tool but man it's great to have such a tool, debugging concurrency bugs is a real pain.

Go has such a great set of tools, it's definitely one of the reason I love it so much. The Go team did an amazing job on this.

Yes, this is pretty freaking cool.

Hopefully it works on Windows too, which is my main OS when I'm working with Go. It seems Windows is a second class citizen when it comes to some of the toolchain (pprof is kinda broken, I can't get addresses to resolve to symbols and just end up profiling on Linux), but fingers crossed!

It does work on windows/amd64.

We're trying hard to keep Windows well-supported. The pprof story is a little sad, as it was a very unix-centric tool to begin with.

> We're trying hard to keep Windows well-supported

As another Go developer on Win7, thanks, I think a lot of people really do appreciate this.

I've worked for years under Linux and OSX as well, but when I started dabbling in OpenGL via Go last year, I switched to Win7 for better nvidia gpu drivers (and Steam), simple as that. If you keep other MS crap I mean software off a Win7 system, it's a rock-solid developer OS with msys/mingw and Sublime Text and Go. I wouldn't touch Win8 but my 7 setup is absolutely working for me as of now. Ultimately I'll have to head back to a Unix seeing the direction Windows is taking, but I'm really happy to be able to work in Go as a first-class citizen for the time being.

Also given today's prevalence of Unixes in developer circles, Win7 is ironically the only OS giving off that "bad-ass underdog" vibe..

I made pprof work, on my machine at least, by replacing the Unix-style directories with Windows ones. /dev/null -> NUL and /tmp -> $ENV{'TEMP'} in the perl script.

I can wholeheartely recommend this tool. With tsan I found a lot of races in parrot threads, which I didn't detect in months before. Those were all real issues. http://blogs.perl.org/users/rurban/2012/08/threadsanitizer.h...

Was coming here to post just that! It's a really terrific tool, I'm really happy to see the Go team providing great default tools with the distribution.

The scary part about this is that I had two race conditions in my code, and they never manifested themselves when the code was live. They were just sort of lurking there. Now I'm paranoid about my non-Go code. Turns out I don't understand concurrent programming as well as I thought I did. Even when I thought I was being really disciplined and organized about my concurrency, I actually wasn't.

The more I read about it, the more I want to learn Go before C/C++. Is there any reason not to?

It will certainly take a lot less time to learn Go than C, and even moreso compared to C++.

Unless you're building a database or a game, it's probably fast enough.

While I wouldn't use Go to make a game because of lack of good libraries/frameworks, performance is fine for less-demanding games (2d, stuff, minecraft, etc)

It's worth noting to joelg236 that you can easily drop C into your Go program using CGO (http://golang.org/cmd/cgo/) for parts that need to be extremely performant. You incur a context switch overhead but it can really boost performance in some use cases.

I would suggest learning Nimrod (http://nimrod-code.org) instead.

why?? what does nimrod bring to the table... how is it better that c/c++ and go ??

Here's why: https://news.ycombinator.com/submitted?id=dom96

That doesn't really explain anything.

There are many things which in my opinion set Nimrod apart. Its syntax is python-like with a mix of Pascal which I prefer over Go's C-like syntax. Nimrod has a very powerful type system with generics, it also has AST macros and templates which Go does not have, it has exceptions which are not discouraged from being used (and gives you a nice stack trace when things go wrong), it also has first class iterators and it compiles to C, C++, Objective C and JavaScript. By compiling to C it makes wrapping C libraries very easy and a tool called c2nim makes this process even easier. Oh, and it has exception tracking and a very cool effects system.

showing off that your language has features that Go doesn't have is kinda missing the point of Go. Half of the reason that people like Go is how few features it has; not how many.

Starting with Go you could end up not bothering with C/C++.

But why is that? If you're goal is to be a very knowledgeable and proficient programmer, I find not knowing C/C++ at all to be a lot hard to take seriously.

Because some languages are more enjoyable to code than others.

For example, I learnt C before C++ and found coding in C++ was more enjoyable than coding in C.

Since then I've been doing a lot of C# coding and I find that much nicer than coding in C++.

From what I've seen of Go it's seems quite a nice language. So by getting proficient in Go it might actually be too frustrating to then try and start coding in C/C++.

So this attitude I find hard to take seriously if your goal is to become a well versed, proficient programmer.

I've written a commercial programmer's editor that consisting of about 200,000 lines of C/C++ code.

http://www.zeusedit.com

Now I don't consider myself an expert in C/C++ but after writing and debugging that many lines of C/C++ code I do consider myself proficient.

But that doesn't change the fact that when it comes to languages, I find that C# is easier to work with than C++.

But that is just my opinion.

wow, how long have you been writing that editor for?

That editor evolved over 15 years (Win16, Win32, Win95, Win NT, Windows XP, Windows Vista, Windows 7).

But there was one full re-write in that time.

That's nice but I don't see how this is a serious attack on what I claimed. My claim is simple: promoting ignorance is bad.

You are mistaking 'programmer' with 'computing scientist'.

The goal of a programmer should be to write great programs.

Sometimes that may require discovering new paradigms. Mostly it involves picking up a trusted tool and getting on with it.

Studying programming languages themselves may make you a more knowledgeable programmer but will not necessarily make you a better programmer.

To become a better programmer you simply have to write better programs.

Yes, we are not talking about some random programming language of a textbook like Ada or Algol. Virtually any system you actually interact with in the real world has a very high probability that it was built in C. At one point, it was nearly a lingua franca. I do not argue it is the greatest language or any box you're trying to put me in. I argue that a proficient programmer with the goal of being well versed in programming (not just "computer science" as you dismissively wrote) should be knowledgeable of C and C++ or at least desire to be and not have some strange attitude of promoting it's ignorance ...

What does programming in C++ or whatever has to to with being a "well versed, proficient programmer"?

Who said you have to learn every junk language under the sun?

I don't really see what the downvotes are about, it seems like anti-intellectualism. My thesis is that if you are wholly ignorant of C and C++, you have a large gap in your knowledge of programming. To wit, you will be unable to understand any systems programming out there; for better or worse that's how it is. This is not to say you are an idiot or something if you don't know C, that is not what is being argued. But this attitude of "don't learn C" is just kind of ignorant to me.

I find the backlash against my view sort of ridiculous to see on "Hacker News." This is really not that controversial.

I think you got down-voted because you were speaking in absolutes, rather than being even-handed. If you had said what you just said then—instead of blurting out a one-liner—you would have been more well-received.

Learn in any order you want. I wouldn't completely forgo C and C++ though.

If you really learn C++, it will take some time, of course, but afterwards, you'll be able to swallow any new language in a week or two (or three, for Haskell).

I feel like I've seen this some time ago, with the release of Go 1.1. Perhaps the article itself is new while what it describes isn't. It just feels very familiar despite the recent date.

The race detector was introduced into stable with Go 1.1. This article is what's new, not the race detector.

We discussed the race detector in our Go 1.1 announcement blog post, but only very superficially. If you actually read this article there is an in-depth discussion of two real race conditions that were found by the tool.

Makes sense; thanks.

As a side note the solution to the Discard problem is quite beautiful.

https://code.google.com/p/go/source/detail?r=4b61f121966b

As I read it makes a quick-try to acquire a pre-allocated buffer, otherwise makes its own. Then it makes a quick-try to give the buffer it used back (to be used by another goroutine).

That is a very elegant use of channels to create an optimistic buffer. Enjoyed that read :)

Reply on news.ycombinator.com