2 ms·

> Compare for example the explicit Go concurrency model, that enables you to design a concurrent system, with Java synchronized methods, that for me represents

> Compare for example the explicit Go concurrency model, that enables you to design a concurrent system, with Java synchronized methods, that for me represents “I have no idea of what is wrong with this messy multi-threaded stuff, so let the must lock all this stuff up”. That is not truly simple and it assumes you are stupid and have no idea of what you are doing. This may sound inflammatory, but it actually matches my experience in multiple companies. With one caveat. There are programmers that will learn just enough to be dangerous, who have ingrained the thought that "threads == speed", and will try to sprinkle multi threaded code everywhere. Said code will misbehave, which will cause them to spray "synchronized" keywords all over the codebase – until it stops misbehaving. Or, at least, until bugs cannot be reliably reproduced anymore. Now you have bottlenecks everywhere, even if it did make sense to spread the workload across cores, or when you'd be waiting for I/O otherwise. So many people do not actually know what they are doing. And the prevalent concurrency model in Java doesn't help make sense of what is going on. Over time, cargo culting develops and there will be one single accepted solution codified in company policy. Usually, a sub-optimal one. Go actually gives you better abstractions, so you can rely less on shared memory and more on message passing. Not only that, it makes it simpler to use this approach, vs. a Mutex and shared memory. Which means people will reach out for that first. Go is not alone in this. There are languages that provide even better abstractions(Erlang for one). But Go features tend to be 'good enough'.

candiodari 8y ago
1) Go code has the same locks that java synchronized code is, they're also used a lot 2) Go encourages more threads than java does because of the M:N threading model 3) Go's concurrency primitives (channels and select) is actually more complex than the java equivalents 4) Go's concurrency gives the programmer less control (e.g. how do you say, I want max 40% cpu time spent on X ?) In my opinion the big thing that protects Go is twofold: a) Go is still not very common among bad programmers. Java is. b) it is much harder to write large Go programs than it is to write large Java programs. That doesn't make those big Java programs bad. Some problems are big and require big solutions, say, CAD, or a company platform. Go is frankly unfit for those problems. Especially because Java has tooling that makes analyzing and working on large programs feasible and Go has at best the very beginnings of such tooling.

candiodari 8y ago

1) Go code has the same locks that java synchronized code is, they're also used a lot 2) Go encourages more threads than java does because of the M:N threading model 3) Go's concurrency primitives (channels and select) is actually more complex than the java equivalents 4) Go's concurrency gives the programmer less control (e.g. how do you say, I want max 40% cpu time spent on X ?) In my opinion the big thing that protects Go is twofold: a) Go is still not very common among bad programmers. Java is. b) it is much harder to write large Go programs than it is to write large Java programs. That doesn't make those big Java programs bad. Some problems are big and require big solutions, say, CAD, or a company platform. Go is frankly unfit for those problems. Especially because Java has tooling that makes analyzing and working on large programs feasible and Go has at best the very beginnings of such tooling.