> There is a trade-off being verbosity and maintainability, IMGO Go hits that.
This is where we'll always disagree, because if you like Go, it's natural for you to come up with this argument, however the line you're drawing is completely arbitrary. I have yet to hear an argument about what makes Go strike a fine balance between verbosity and maintainability, when my feelings are the opposite - I find Go code to not be very maintainable in comparison with other static languages, because Go is not very statically type-safe.
> LOL. Said no person who has actually distributed a multiplatofrm Java application ever
Yet it happens all the time and a LOL is not an argument that disproves that. From my own experience, I have built stuff on top of Java / the JVM on OS X / Linux and deployed on Linux, Windows and OS X, without encountering any issues, ever, without worrying that Java's NIO will work or not, without worrying on whether the memory model will suddenly be different, without worrying on whether my app will leak on 32 bits platforms ;-)
Android is the only ugly duckling, but that's only because Android doesn't have a JVM on it. It still works out well though.
But if you have examples, I'd love to hear them out.
> The key word here was dependency, specifically, external dependency. If Go'd runtime ships with the binary its not really a external dependency is it.
Now that's an arbitrary distinction, isn't it? What stops one from bundling the VM in the same deployed binary? If you want this distinction, the only valid argument is one of size, but then again for the server-side (where most of the Go stuff is used) that's completely meaningless.
> Yes. It comes baked into the stdlib, its "http/pprof"
Are you seriously comparing something like YourKit's Profiler and Java's remote attach and debugging capabilities to http/pprof? IMHO, that's not a comparison you can make.
> Biggest plus ever, goes native simple tooling doesn't need an external life support system.
There are many issues wrong with this line of thinking - the simple tooling you're talking about doesn't do what I and many others want it to do. Also if you look throughout history, all the languages that came with batteries included have suffered once the people finally reached the conclusion that the included batteries have been shitty. Which is what happens when you don't let evolution pick a winner with the community acting as the fitness function. But we'll talk in about 5 years.
> You are wrong, all the the stuff you are are talking about is library based, Go has channels/select/go build into the language as primitives. I wasn't talking about bolt on libraries.
But that's the point mate, the JVM is capable enough to build anything you want on top of it as libraries, there's no point for something to be hard-coded in the language. Which is a good thing, because when speaking of concurrency and parallelism, there isn't a one size fits all.
For example, speaking of Go's channels - they are strictly about managing concurrency, they are not about parallelizing a workload and they do not work across address spaces / asynchronous boundaries. And if you think that Go's channels are the answer to everything, well, you would have been better off with Erlang, as there you might have had a valid argument.
> IMHO This is not the case, if you think it is, explain.
Can you take an arbitrary memory location and cast it to anything you want? Can you override how heap allocation happens? Can you allocate an array on the stack? Can you do RAII? Do you have the union type from C?
In practice you have no control on where Golang allocates stuff - the compiler decides that based on really simple rules for escape analysis and as a general rule of thumb AFAIK anything that is allocated with "new" goes on the heap. What you can do with Golang is to use the "unsafe" package. But that's not different than using Java's sun.misc.unsafe ;-)
The only real difference with Golang is that you can have stack allocated structs, as otherwise Java also does escape analysis. But besides this coming to Java 9, the real kicker is that .NET/C# has had stack allocated values since inception, in addition to much more potent "unsafe" constructs - in C# you can even do pointers and pointer arithmetic and the runtime will pin those memory addresses during execution for avoiding GC interference.
I could respond point by point and keep this going, but don't think we are going to change each-other's mind or add constructively to this conversation.
I think we would both like to think we are both right on technical grounds, but I think we would be deceiving ourselves as a great proportion of this is personal taste, ideological, and we are both heavily invested in our respective platform of choice.
This is where we'll always disagree, because if you like Go, it's natural for you to come up with this argument, however the line you're drawing is completely arbitrary. I have yet to hear an argument about what makes Go strike a fine balance between verbosity and maintainability, when my feelings are the opposite - I find Go code to not be very maintainable in comparison with other static languages, because Go is not very statically type-safe.
> LOL. Said no person who has actually distributed a multiplatofrm Java application ever
Yet it happens all the time and a LOL is not an argument that disproves that. From my own experience, I have built stuff on top of Java / the JVM on OS X / Linux and deployed on Linux, Windows and OS X, without encountering any issues, ever, without worrying that Java's NIO will work or not, without worrying on whether the memory model will suddenly be different, without worrying on whether my app will leak on 32 bits platforms ;-)
Android is the only ugly duckling, but that's only because Android doesn't have a JVM on it. It still works out well though.
But if you have examples, I'd love to hear them out.
> The key word here was dependency, specifically, external dependency. If Go'd runtime ships with the binary its not really a external dependency is it.
Now that's an arbitrary distinction, isn't it? What stops one from bundling the VM in the same deployed binary? If you want this distinction, the only valid argument is one of size, but then again for the server-side (where most of the Go stuff is used) that's completely meaningless.
> Yes. It comes baked into the stdlib, its "http/pprof"
Are you seriously comparing something like YourKit's Profiler and Java's remote attach and debugging capabilities to http/pprof? IMHO, that's not a comparison you can make.
> Biggest plus ever, goes native simple tooling doesn't need an external life support system.
There are many issues wrong with this line of thinking - the simple tooling you're talking about doesn't do what I and many others want it to do. Also if you look throughout history, all the languages that came with batteries included have suffered once the people finally reached the conclusion that the included batteries have been shitty. Which is what happens when you don't let evolution pick a winner with the community acting as the fitness function. But we'll talk in about 5 years.
> You are wrong, all the the stuff you are are talking about is library based, Go has channels/select/go build into the language as primitives. I wasn't talking about bolt on libraries.
But that's the point mate, the JVM is capable enough to build anything you want on top of it as libraries, there's no point for something to be hard-coded in the language. Which is a good thing, because when speaking of concurrency and parallelism, there isn't a one size fits all.
For example, speaking of Go's channels - they are strictly about managing concurrency, they are not about parallelizing a workload and they do not work across address spaces / asynchronous boundaries. And if you think that Go's channels are the answer to everything, well, you would have been better off with Erlang, as there you might have had a valid argument.
> IMHO This is not the case, if you think it is, explain.
Can you take an arbitrary memory location and cast it to anything you want? Can you override how heap allocation happens? Can you allocate an array on the stack? Can you do RAII? Do you have the union type from C?
In practice you have no control on where Golang allocates stuff - the compiler decides that based on really simple rules for escape analysis and as a general rule of thumb AFAIK anything that is allocated with "new" goes on the heap. What you can do with Golang is to use the "unsafe" package. But that's not different than using Java's sun.misc.unsafe ;-)
The only real difference with Golang is that you can have stack allocated structs, as otherwise Java also does escape analysis. But besides this coming to Java 9, the real kicker is that .NET/C# has had stack allocated values since inception, in addition to much more potent "unsafe" constructs - in C# you can even do pointers and pointer arithmetic and the runtime will pin those memory addresses during execution for avoiding GC interference.