> 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.<p>This may sound inflammatory, but it actually matches my experience in multiple companies.<p>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.<p>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.<p>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.<p>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'.
Needs a "2016" in the title.<p>I've mostly skimmed this article but based on what I'm seeing it's more of the same, "Concurrency", "Simplicity", "Simple deployment" etc.<p>I would really like to learn something else about Go now, when is Python a better choice? When is Rust a better choice? What are the negatives of using Go?
Nothing new here. Same reiteration you'd expect from someone coming from Javascript/Python/etc.<p>Nothing that Java, C#, etc. wouldn't give you (other than hype based development perhaps).