I think Golang has a fondness for magical (to me) special language constructs. For example if you want to use the RPC modules, you have to write your functions a certain way. Or as I've explained in a comment above, if you want to use an interface you just have to implement all it's properties. Or you can't have generics, but we have a special language construct called maps, where you kind of can mimick genericks but it is not safe and may break.
Golang is a great language, but I think it expects all its users to think very rigidly in the same way their designers do. Basically, you have to explore the language's deficiencies yourself, read the designers' explanations, dive into the intrinsics of the language, understand it, make yourself believe and move on. I sometimes half-jokingly feel like Golang follows the principle of most obedience.
Apparently also not about sync.Mutex =)
> if you want to use an interface you just have to implement all it's properties
You surely mean "methods" --- don't interfaces work like that everywhere they exist?
As for the second point, sorry for the wrong wording, I meant "methods". But interfaces don't work like that everywhere they exist. For example in Java you explicitly use Class X implements Y, and if you do not implement all methods and properties, the compiler complains.
Don't know about your exact map use-case you had at hand, but generally speaking the Mutexes suffice for Lock()ing/Unlock()ing a resource that is accessed concurrently, whereas the WaitGroups serve usually best to just fire off a couple of parallel jobs (that don't access any shared-between-them resources) and then simply Wait() for them all to finish. No real protection from concurrent accesses in there, other than for the WaitGroup's own hidden internal counter that's used to Wait()
Of course these are the low-level sync primitives, channels are the higher-level abstraction, but the former can take you far --- sometimes the latter are the sanest/only choice of course. Especially for parallel goroutines needing to work with each other's intermediate results.
What Java does have (since 8) is default method implementations in interfaces.
Interfaces cannot require instance variables to be defined -- only methods.
(Variables can be defined in interfaces, but they do not behave as might be expected: they are treated as final static.)(Another useful link explaining that statements resembling instance variables in interfaces are in fact constants: https://coderanch.com/t/178630/certification/Instance-variab...)
Don't blame the language for your buggy code.
Unless otherwise stated, Go's data structures are not thread-safe. Maps are not thread safe.
In that respect Go isn't different from any other mainstream language with pre-emptive threading (C++, Java, C#).
It’s not as if every block is sending out each line to run in a separate goroutine. Go encourages users to share data by communicating, not communicating by sharing data [0].
On phone, sorry for syntax
struct CMap {
sync.RWMutex
i int
}
func (m *CMap) Inc() {
m.RWLock()
defer m.Unlock()
m.i++
}
for instance, in a for loop ranging over a slice:
for _, i := range some_slice {
go func() {
something(i)
}()
}
for your example, you can look to the newly added sync/map which uses interface{} everywhere as an example of how the lack of generics have left users with no _sensible_ tools to remedy these kinds of language problems. how wonderful would an efficient thread-safe and type-safe concurrent map be? it's possible in many other modern and not so modern programming languages, but it is intentionally not possible in go.
for (int i : someCollection) {
pool.execute(() -> something(i));
}
No, DO blame the language if its the one that enables and allows for said buggy code when it could as well prevent it.
Case in point: http://lambda-the-ultimate.org/node/3186
However a common situation is that the language is supporting a wide range of uses, not just the use a particular developer has in mind at the time.
I've seen this most commonly where a developer operating at a higher level of abstraction, without understanding low level details, complains that the language doesn't match his high level needs exactly.
When in fact it supports lower level operations for maximum performance or flexibility, while allowing layering on top for higher level uses. In language design it's essential to support the lowest level use cases you are targeting, because you can build on top but not go lower than the language exposes (unless it supports embedded asm or another trick to go lower again). I'm using higher/lower here only to refer in the sense of the level of abstraction.
It's a really common trap for someone working usually at one level of abstraction and not deeply understand other levels, to not understanding why a language or library is the way it is because if needs to support others users needs that are different to ones own - I've done it myself enough to detect the pattern, and seen lots of other people do it. Lurking on design committee discussions can be eye opening!