Really, it has a decent way to manage inter-thread communication - channels. But the language still permits me to read/write a "non const" global variable from a goroutine.
This is horrible, especially when refactoring.
Each goroutine should have it's own scope (unless explicitly defined).
for _, v := range values {
go func() {
// Do stuff with v
}
}
for _, v := range values {
go (func(v string) {
// Do stuff with value
})(v)
}
I like to say that Go's strictness is unevenly distributed. Unused imports are illegal, but Go is perfectly happy to let you shadow variables, have closure use loop variables, or reassign the built-in values ("nil", "true", etc.). It's like a parent who locks the scissors away in a drawer but doesn't mind leaving drain cleaner on the kitchen table.
This code results in a compilation error:
for v in values {
spawn(|| {
// Do stuff with v
});
}
error[E0373]: closure may outlive the current function, but it borrows `v`, which is owned by the current function
--> <anon>:7:15
|
7 | spawn(|| {
| ^^ may outlive borrowed value `v`
8 | v;
| - `v` is borrowed here
|
help: to force the closure to take ownership of `v` (and any other referenced variables), use the `move` keyword, as shown:
| spawn(move || {
As the error message says, the real problem with this code, given Rust's semantics, is that the closures are being given pointers to memory that might not be valid by the time the closure gets around to executing (unlike in Go (or any other GC'd lang), the mere existence of a pointer is not enough to keep memory alive). And as the help text at the bottom of the error message describes, one solution is to have the closures themselves assume ownership of the data via the `move` keyword on closures.
I'm very thankful to that level of dedication.
Prior to Java 8, which introduced lambdas, variables used with anonymous classes were required to be final. That restriction is now relaxed as the compiler can infer it.
Interestingly, the for-each loop variable is effectively final, unless you explicitly modify it, so this code is legal (and correct):
for (String v : values) {
executor.execute(() -> System.out.println(v));
}* the default is similar to [&] but will infer the capture mode and use the "simplest" possible one (reference, mutable reference or value) depending on use on a per-value basis.
* `move` closures are similar to [=] but will use Rust ownership semantics, so they will copy Copy values and move non-Copy values, it can capture external references (mutable or not) by value so if you needed to explicitly tweak your capture that's the one you'd use.
[0] OTOH it's more readable
The point of enforcing final variables is to prevent programmers from accidentally modifying things they don't want to. It does not prevent programmers from modifying variables intentionally.
Furthermore, it does not cause you to lose "all the power of real closures" like you said it does. All you lose is the ability to use a closure around non-final variables, which is a trivial drawback in any use case I've ever come across. You lose only a little bit of the power of closures.
const?
(A shadow variable problem in C just turned up in firmware for a surface mount reflow soldering oven I have. The variable name is "avgtemp". This may explain why some ovens scorch PC boards.[1] Read the discussion. Note that none of the people writing about the issue understand that "static" would confine the scope to one file, and that uninitialized variable declarations at top level are global to the whole program. That's probably because they came up from Arduino land, where people are not taught to think about that stuff. Arduino land is really full C++ using gcc, but it's not taught that way.)
[1] https://github.com/UnifiedEngineering/T-962-improvements/iss...
That seems a bit surprising, unless they did not know C even reasonably well. IIRC (though I haven't used C much lately, I did a lot with it earlier), that is a not-too-advanced feature of the C language. I think it is covered in the K&R C book, near the middle or in the latter half (don't have it handy right now to check).
I think Go's strictness is very practical -- it's strict where they saw real problems and the cure was easy.
Something like threading race conditions is a real problem, but not easy to fix.
Go does give you a pretty good runtime tool with the race checker, though. It would quickly catch something like the fish bug of grabbing the wrong lock.
It is. It's called channels.
Rust really fixes this (with its ownership system), but it wasn't easy.
Go allows sending pointers to non-locked structures over channels, so it's quite easy to "only use channels" and still get race.
You can also hit that issue if you spawn multiple goroutines sharing the same initial lexical environment if they make use of a mutable structure from that environment.
So force one to do it consciously (kind of like unsafe).
https://golang.org/cmd/vet/#hdr-Struct_tags
(There seems to be a documentation error.)
And try the race detector:
https://golang.org/doc/articles/race_detector.html
Though of course, it's hard to argue that it would be nice to prevent these from compiling.
"go vet" never warned me about goroutine closure errors, not sure why, maybe I was running an old version. But I'm glad that it's supported.
That said, some of the things that "go vet" catches should, in my opinion, be errors.
What about not-shadowing a "non-loop" variable?
Take a look at this question:
http://stackoverflow.com/questions/18499352/golang-cuncurren...
It's easy to mess up during refactoring, and there's pretty much no reason to allow it.
The closure doesn't get a copy, so what usually ends up happening is that every goroutine gets the last value (since the goroutines are probably not scheduled until the end of the loop).
This problem doesn't just affect loops, of course: A goroutine can access any local environment outside its scope, and local variables can mutate.
The worst surprise I ever encountered was this (simplified):
func makeWorkersDocomplicatedStuff()
ch := make(chan string)
defer func() {
if ch != nil {
close(ch)
}
}
for i := 0; i < numWorkers; i++ {
go func() {
for {
select {
case s := <-ch:
// ...
}
}
}
}
close(ch)
ch = nil
// ... More stuff ...
}
Rewriting and refactoring this was trivial enough, but catching it was time wasted. Lessons learned: (1) Be scrupulous about closure environments, (2) be super careful about nil channels, and (3) try to avoid defers whose concerns don't fully encapsulate the function body (so defers in the middle of a function is often code smell).
In Rust this is not true. However, the same concept applies - say it was a variable from outside the loop. In that case, you would get a clear compile time error about moving the value into the thread's closure more than once.
A similar error would apply if you iterated over a container by reference (instead of by value).
(Almost every Go program I've written uses goroutines so I end up using locks in almost every program I write)
There's no way to do this without language support or sacrificing perf with interface, so I get why nicer locks don't exist, I just wish they did.