A million ways to die from a data race in Go
21–30 of 146 posts
Re: A million ways to die from a data race in Go
#22Only looked at the first two examples. No language can save you when one writes bad code like that.
You can argue about how likely is code like that is, but both of these examples would result in a hard compiler error in Rust. A lot of developers without much (or any) Rust experience get the impression that the Rust Borrow checker is there to prevent memory leaks without requiring garbage collection, but that's only 10% of what it does. Most the actual pain dealing with borrow checker errors comes from it's other j…
Rust concurrency also has issues, there are many complaints about async [0], and some Rust developers point to Go as having green threads. The original author of Rust originally wanted green threads as I understand it, but Rust evolved in a different direction.
As for Java, there are fibers/virtual threads now, but I know too little of them to comment on them. Go's green thread story is presumably still good, also relative to most other programming languages. Not that concurrency in Java is bad, it has some good aspects to it.
[0]: An example is https://news.ycombinator.com/item?id=45898923 https://news.ycombinator.com/item?id=45903586 , both for the same article.
Re: A million ways to die from a data race in Go
#23In the first one, he complains that one character is enough to cause an issue, but the user should really have a good understanding of variable scope and the difference between assignment and instsntiation if they're writing concurrent go code. Some ides warn the user when they do this with a different color. Races with mutexes can indicate the author either doesn't understand or refuses to engage with Go's message b…
The mutex case is one where they're using a mutex to guard read/writes to a map. Please show us how to write that cleanly with channels, since clearly you understand channels better than the author. I think the golang stdlib authors could use some help too, since they prefer mutexes for basically everything (look at sync.Map, it doesn't spin off a goroutine to handle read/write requests on channels, it uses a mutex).…
For that last example, if 'item' is immutable, there is no issue, correct?
Re: A million ways to die from a data race in Go
#24Earlier quoted context omitted.
You can argue about how likely is code like that is, but both of these examples would result in a hard compiler error in Rust. A lot of developers without much (or any) Rust experience get the impression that the Rust Borrow checker is there to prevent memory leaks without requiring garbage collection, but that's only 10% of what it does. Most the actual pain dealing with borrow checker errors comes from it's other j…
Rust concurrency also has issues, there are many complaints about async [0], and some Rust developers point to Go as having green threads. The original author of Rust originally wanted green threads as I understand it, but Rust evolved in a different direction. As for Java, there are fibers/virtual threads now, but I know too little of them to comment on them. Go's green thread story is presumably still good, also re…
Async and concurrency are orthogonal concepts.
Re: A million ways to die from a data race in Go
#25Earlier quoted context omitted.
"best in class"? I feel like Java's IDE support is best in class. I feel like go is firmly below average. Like, Java has great tooling for attaching a debugger, including to running processes, and stepping through code, adding conditional breakpoints, poking through the stack at any given moment. Most Go developers seem to still be stuck in println debugging land, akin to what you get in C. The gopls language server…
Java best in class? I love java. It is my first love but ill take go ecosystem 1000% of the time.
Mind explaining your debugging setup, i.e. which IDE you use and what tooling you use to be able to step through and reason about code?
Re: A million ways to die from a data race in Go
#26Earlier quoted context omitted.
The mutex case is one where they're using a mutex to guard read/writes to a map. Please show us how to write that cleanly with channels, since clearly you understand channels better than the author. I think the golang stdlib authors could use some help too, since they prefer mutexes for basically everything (look at sync.Map, it doesn't spin off a goroutine to handle read/write requests on channels, it uses a mutex).…
For that last example, if 'item' is immutable, there is no issue, correct?
Yeah, indeed.
Developers have a bad habit of adding mutable fields to plain old data objects in Go though, so even if it's immutable now, it's now easy for a developer to create a race down the line. There's no way to indicate that something must be immutability at compile-time, so the compiler won't help you there.
Re: A million ways to die from a data race in Go
#27Earlier quoted context omitted.
Rust concurrency also has issues, there are many complaints about async [0], and some Rust developers point to Go as having green threads. The original author of Rust originally wanted green threads as I understand it, but Rust evolved in a different direction. As for Java, there are fibers/virtual threads now, but I know too little of them to comment on them. Go's green thread story is presumably still good, also re…
Async and concurrency are orthogonal concepts.
Could you give an example to distinguish them? Async means not-synchronous, which I understand to mean that the next computation to start is not necessarily the next computation to finish. Concurrent means multiple different parts of the program may make progress before any one of them finishes. Are they not the same? (Of course, concurrency famously does not imply parallelism, one counterexample being a single-threaded async runtime.)
Re: A million ways to die from a data race in Go
#28All code is inherently not concurrency-safe unless it says so. The http.Client docs mention concurrent usage is safe, but not modification.
The closure compiler flag trick looks interesting though, will give this a spin on some projects.
Re: A million ways to die from a data race in Go
#29I dislike some of this article, my impression is similar to some of the complaints of others here. However, are Go programs not supposed to typically avoid sharing mutable data across goroutines in the first place? If only immutable messages are shared between goroutines, it should be way easier to avoid many of these issues. That is of course not always viable, for instance due to performance concerns, but in theory…
Go is a weird one, because it's super easy to learn -if- you're familiar with say, C. If you're not, it still appears to be super easy to learn, but has enough pitfalls to make your day bad. I feel like much of the article falls into the latter camp.
I recently worked with a 'senior' Go engineer. I asked him why he never used pointer receivers, and after explaining what that meant, he said he didn't really understand when to use asterisks or not. But hey, immutability by default is something I guess.
Re: A million ways to die from a data race in Go
#30Earlier quoted context omitted.
"best in class"? I feel like Java's IDE support is best in class. I feel like go is firmly below average. Like, Java has great tooling for attaching a debugger, including to running processes, and stepping through code, adding conditional breakpoints, poking through the stack at any given moment. Most Go developers seem to still be stuck in println debugging land, akin to what you get in C. The gopls language server…
Java best in class? I love java. It is my first love but ill take go ecosystem 1000% of the time.
It absolutely is. There is not many ecosystems where you can attach a debugger to a live prod system with minimal overhead, or one that has something like flight recorder, visualvm, etc.