> 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'.
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.
I've mostly skimmed this article but based on what I'm seeing it's more of the same, "Concurrency", "Simplicity", "Simple deployment" etc.
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?
There are plenty of articles comparing Rust and Go. Easy to find.
When it comes to Go itself, You have both those pros listed in this article and repeated everywhere, and these cons listed in Reddit and again repeated everywhere. In my opinion cons will weight more and becomes annoying when you are working on a large projects/code-base, Otherwise for smaller projects you don't notice them much and performance and goroutines are the main reasons for MOST not ALL projects choosing Go over Python or Ruby in that scale.
I find it ironic that golang was supposedly created for "large scale" programming, but nothing really in the language supports that notion (no dependency management, import system sucks, verbose error handling, and so on). I just see the claim without anything to back it up.
Yes, that's what I meant, and it does a bad job at it (the examples I gave). Java/C#/Kotlin/etc. are strictly superior when it comes to managing large code bases.
I think what they had in mind is just quick compilation times, even at the expense of convenience, safety, terseness, etc.
Not only tiny on disk (startup time, pulling etc) but also tiny memory footprint. I'm comparing to a Java Spring app and Golang is absurdly light on memory.
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'.