On Tue, Sep 13, 2016 at 7:53 AM josvazg <josv...@gmail.com> wrote: > Why does Go does not have a static race detector? What are the difficulties?
For example, the halting problem. Ok, now seriously. > If Rust can do it, using its ownership model, Go could have a tool checking the AST that analyzes variable scopes and checks globals, variables passed to goroutines and to/from channels. > > If one such followed variable is found in any piece of code to be accessed from more than 2 places and any access is a write, bam! flag that code with an error. I don't speak Rust, but AFAIK, its model of ownership does not provide static race detecting, but can prove a race cannot happen, ie. no two paths can concurrently read and write the same data. But a Go program can be perfectly reasonable and completely race free even if it can be proven by Rust's model as having a potential for races - assuming the Go program uses synchronization properly. Proper synchronization avoids races, but it is not possible in the general case to prove the synchronization is used properly, because - the halting problem etc. OTOH, a program proving that a particular Go program cannot have a race is IMO possible to write. What I doubt is its value, because Go code which can be proven race-free is probably only a small subset of Go code people write. -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.