Well, that's the same in any concurrent application. If you don't think about race conditions while coding, you shouldn't be using a concurrent language.
This is the same for anything. For example, a webserver written in C++ that uses pthreads might have a #define that determines the number of threads in the thread pool. If the default is 1 and nobody changes this in development, it should not break when someone changes it to 2 or 3, otherwise the code is wrong.
As for your argument about Java, there's nothing you can do in Java that you can't do in assembly. This argument is invalid. Go's strength is in making complex things simple. For example, if you wanted to build a distributed system (across machines), in Go you just use "net/rpc" it would handle it for you. In Java, you'd have like 3 layers of abstract classes that define a serializable type, you'd make some kind of listener class that receives responses from an RPC call, and do tons of other boilerplate. In Go, you just make a function call. That's it.
What exactly can't you do in Go that you can do in Go? Maybe generics, but that just complicates code unnecessarily most of the time. Sure, I've done my share of generic programming, but I've also written non-trivial, several thousand LOC programs in Go, and my Go code was much simpler and easier to read.
BTW, Java sucks for concurrent programming. I hate that stupid Runnable interface (or whatever they call it these days). I'd much rather have a bunch of functions that can be called synchronously, or in a go-routine and have simple checks in place to eliminate race conditions.
In Java, you'd have like 3 layers of abstract classes that define a serializable type, you'd make some kind of listener class that receives responses from an RPC call, and do tons of other boilerplate.
Or you just add Akka to your pom and pass messages between actors. (If using Scala, the syntax is tightened up very nicely.)
This is the same for anything. For example, a webserver written in C++ that uses pthreads might have a #define that determines the number of threads in the thread pool. If the default is 1 and nobody changes this in development, it should not break when someone changes it to 2 or 3, otherwise the code is wrong.
As for your argument about Java, there's nothing you can do in Java that you can't do in assembly. This argument is invalid. Go's strength is in making complex things simple. For example, if you wanted to build a distributed system (across machines), in Go you just use "net/rpc" it would handle it for you. In Java, you'd have like 3 layers of abstract classes that define a serializable type, you'd make some kind of listener class that receives responses from an RPC call, and do tons of other boilerplate. In Go, you just make a function call. That's it.
What exactly can't you do in Go that you can do in Go? Maybe generics, but that just complicates code unnecessarily most of the time. Sure, I've done my share of generic programming, but I've also written non-trivial, several thousand LOC programs in Go, and my Go code was much simpler and easier to read.
BTW, Java sucks for concurrent programming. I hate that stupid Runnable interface (or whatever they call it these days). I'd much rather have a bunch of functions that can be called synchronously, or in a go-routine and have simple checks in place to eliminate race conditions.