Hacker News Reader

Comment by heyoni | Hacker News Reader

Go has a race detector that you can leave on for a while in like a dev environment and it’ll flag race conditions. There was documented overhead and at some point even a memory leak but they spent months looking into it and eventually plugged the leak and the saga is now part of their official docs. It’s really interesting to see that kind of stuff laid bare so I would trust that this feature will at least run reasonably well and if it doesn’t, they’ll likely fix it: https://go.dev/doc/articles/race_detector https://go.dev/issue/26813

View on HN

The race detector is an invaluable complement to a language like Go that lacks compile time safety. It meaningfully increases the confidence in code and is anecdotally both good at finding races while also giving straightforward error information to plug them. It won’t find everything though, since it’s runtime analysis.

In general, Go tooling makes up for a lot of the intrinsic issues with the language, and even shines as best in class in some cases (like coverage, and perhaps tracing too). All out of the box, and improving with every release.

Only if we leave Smalltalk, Erlang, Java and .NET ecosystems out of the picture.

Ah yes, the notoriously popular and actively contributed Smalltalk ecosystem.

Doesn't change the fact of being there first, with a rich standard library, and one of the ecosystems that drove the design of rich developer tooling, decades before Go was even an idea.

No on claims Go was "first"; I don't get why you're so obsessed by that. The previous poster just said "The race detector is an invaluable complement". And it is. There was no comment at all about any other language; it just says "this is a nice thing about Go".

If you don't like Go then fine, no problem. Everyone dislikes some things. No hard feelings. But why comment here? What's the value of just stinking up threads like this with all these bitterly salty comments that barely engage with what's being said? Your comments alone consist 13% of this entire thread, and more if we could all the pointless "discussions" you started. It's profoundly unpleasant behaviour.

The Go community is quite deep into it being the first into fast compilers, co-routines, slices, static compilation, and rich standard libraries.

The commenter said more than that.

"In general, Go tooling makes up for a lot of the intrinsic issues with the language, and even shines as best in class in some cases (like coverage, and perhaps tracing too). All out of the box, and improving with every release."

Best in class?!?

> The cost of race detection varies by program, but for a typical program, memory usage may increase by 5-10x and execution time by 2-20x.

That's "let's run the race detector and get some coffee" overhead, not "let's leave it on in dev" overhead.

Still cool that they have it available!

I am always running everything in race mode when developing locally and have caught stuff before.

The main value of the race detector is enabling it for tests (go test -race), and then writing sufficiently exhaustive unit tests to cover all code paths.

I do think most gophers, instead of tests, use a combination of prayer and automatically restarting crashed processes when they inevitably panic from a race, which seems to work better than you'd expect!

Reply on news.ycombinator.com