> - I'm surprised Go gets a 1.0 for thread safety, while Java only gets a 0.5. My understanding is that, at the lowest level, producing e.g. a torn pointer is not possible in the Java memory model, while it is possible in Go.
Some of the original reasoning behind the numbers is swapped out, but much of this scoring was that we were burnt so much by the ease of passing objects between threads and accidentally racing that we dinged Java. Our company's experience with Go has just been better, but Go also has first-class goroutines that mostly enforce doing stuff "right", and had better tooling around multithreaded race detection [1] especially at the time.
> - I think C++ deserves at least a point or two over C for thread safety, for the same reason it gets a couple points for memory safety. The distinction between raw pointers and smart pointers makes it a lot clearer who is supposed to be owning what, and seeing shared_ptr in the code can be a good reminder that something is likely to race.
That's a good point. We might have scored it somewhat differently if we were more familiar with C++ at the time but most of our C++ knowledge on the team was pretty old, and especially sparse around multi-threading.
> - Is Rust really harder to learn than C++? :) I'd normally give C++ a lot of points for familiarity, but that's already split into a separate row.
IIRC, the rationale was that C++ is mostly familiar concepts that senior developers have encountered in some form, while Rust introduces brand new concepts that we just don't have a good reference point for.
This is absolutely fuzzy business, and a different team will have different weights/scores than us!
[1] https://blog.golang.org/race-detector