"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.
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!
> 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.
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.
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++.
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 ...
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.
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.
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)
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).
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.
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.
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.
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 :)
