- Go codebases by non experts are peppered with magical incantation (sleeps, etc.) to avoid the dreaded "all goroutines are sleep". Of course "they are doing it wrong", but that is the germinal point.
- A concurrent Go program will likely behave differently given 2 bits (just 2 lousy bits) of difference in the object binary. (runtime.GOMAXPROCS(1) vs runtime.GOMAXPROCS(2)). Imagine someone touching those 2 bits in a "large codebase". It is practically impossible to do the same thing in a large Java codebase and fundamentally change the programs runtime behavior. (Happens all the time in Go.)
- It is very difficult to reason about a Go routine's behavior in a "large codebase" without global view and a mental model of the dynamic system e.g. which go routine is doing what and who is blocking and who is not. Pretty much defeats the entire point of "simple" concurrency, to say nothing of "scaling". Programming in Go's variant of cooperative multithreading is actually more demanding than preemptive multithreading. Cute little concurrency pet tricks aside, Go concurrent programming actually requires expert level experience. "You are doing it wrong". Of course. Point.
- There is nothing, absolutely nothing, that you can do in Go that you can not do via libraries in Java. Sure, the cute syntactic go func() needs to be replaced with method calls to the excellent java.util.concurrent constructs, but the benefits -- high performance, explicit-no-magic-code -- outweigh the cute factor in this "programmer's" book.
- On the other hand, there are plenty of things you can do in Java that are simply impossible to do in Go.
- Once we factor in the possibility for bytecode engineering, then Java is simply in another higher league as far as language capabilities are concerned. (Most people who rag on Java are clearly diletantes Java programmers.)
If Go actually manages to be as effective as Java for concurrent programming at some point in the future (when they fix the somewhat broken runtime) then the Go authors are permitted to crow about it. Until that day, go fix_the_runtime() and defer bs().
One thing that programming in Go has made me realize is just how awesomely Sun/Gosling, et al. hit that "practical programming" sweet spot. No wonder the modern enterprise runs on Java and JVM.
It just works. (But it is "boring" because it's not bling anymore. Oh well, kids will be kids.)
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.)
>There is nothing, absolutely nothing, that you can do in Go that you can not do via libraries in Java
Yes there is.
You can run thousands of concurrent goroutines. Creating thousands of threads in Java will bring the system to its knees. java.util.concurrent doesn't solve the stack size problem.
You can have compact structured value types in Go but not in Java, meaning Java will always eat a lot more memory than Go.
In Java you can use executors and thread pools to "start thousands of threads" in the same way those "thousends of concurrent goroutines" are running "in the same time" on a modern 16 core cpu.
That's not true at all. Each goroutine has its own variable sized stack whereas Runnable objects in Java don't have a stack of their own. They use the thread's stack. So as long as a Runnable uses its stack (that is the run() method hasn't finished), the thread cannot be used by other Runnables.
So, in Go you can have thousands active function invocations (i.e tens of thousands of stack frames on thousands of stacks) at the same time and they do not occupy thousands of threads. You can't do that in Java.
I'm talking about every single Java language implementation that I know of. And I believe (although I'm not completely sure) that the Java language specification requires it at least implicitly.
No you did not. You stated that is not possible in Java at all regardless of the implementation. I don't see any mention of " none of the implementations I know of" on your comment.
<quote>
That's not true at all. Each goroutine has its own variable sized stack whereas Runnable objects in Java don't have a stack of their own. They use the thread's stack. So as long as a Runnable uses its stack (that is the run() method hasn't finished), the thread cannot be used by other Runnables.
So, in Go you can have thousands active function invocations (i.e tens of thousands of stack frames on thousands of stacks) at the same time and they do not occupy thousands of threads. You can't do that in Java.
</quote>
You are being deliberately dense. If no existing JVM gives runnable objects their own stack, then it's impossible for a java developer to create thousands of threads (without creating their own JVM, which is totally unreasonable 99% of the time). It's a practical impossibility. Is that so much worse than a technical one?
That's OK, it's been a perfectly civilised debate after all. You're making a fair point insisting on a distinction between implementations and the spec. My initial posts were very unclear in that regard.
> There is nothing, absolutely nothing, that you can do in Go that you can not do via libraries in Java
Agreed, however there are things I really don't want to do in Java as even using the wonderful selection of libraries and tooling out there they are like sandpapering your face and repeatedly ramming it into a salt bath.
By the time I've set up Eclipse, Maven, Jetty/Glassfish and a reasonable framework, I could have actually finished the task in Go. To be 100% honest, I could probably do it whilst maven is puking in the Eclipse log window.
Go is excellent for prototyping ideas, which is why it is my "language of choice" at the moment. But your argument falls flat when considering deploying "large scale" systems, which have multiple dimensions of ceremony before hitting production.
I disagree. I build very large scale systems. I think that large scale systems should be constructed out of small components which are loosely coupled distributed components with strong contracts between them. These components are ideal for encapsulating in small standalone go components.
That is a viable approach and I share your affinity for that type of architecture, but insisting that it is the only way to build large scale systems is not reasonable. In real life, for example, you have clients and clients have their preferences or requirements or existing systems. And system architects also like having choices.
And speaking of choice in context of massively concurrent CSP systems, Erlang is (as of now) the superior choice for that sort of system architecture.
I think you mean Erlang's strict CSP -- share nothing -- is not as efficient as shared memory systems such as Go. That is a fact and by design it is a feature and not a bug. Nine 9s: http://pragprog.com/articles/erlang
> Have you tried finding Erlang programmers?
Go looks easy but it is a subtle language. Brad F. writes a server and it performs. Mr. X writes one and it crawls. Go figure.
Erlang doesn't scale as in Erlang doesn't scale to larger projects when you require lots of people working on them. I doubt we could put our 2MLOC trading platform into Erlang and get away with it.
It certainly scales from a technology point of view.
Go is simple enough to allow Mr X's code to go through a review by Brad F until Mr X gets the point.
Do you contend that concurrency—and I mean true concurrency in the abstract, not a particular implementation of a parallelization idiom like threads—is well-served by C++ or Java?
I cant speak for the world, but i have a personal, irrational dislike for Java ever since my university standarized on it for almost every subject and assignment. This was before we even had things like generics.
People hate on Java, likely not because its the worst language, but because it was the least favorite language they were forced to use too often. This hate does not reflect a rational opinion, but an experience.
Ands it about a lot more than language features. Its about culture, what it represents, and the type of role it plays in our industry. Like Cobol before it, Java will not escape its faith and it will die. Not because it must die, but because we must kill it.
6 days ago the poster was calling it their "language of choice" and saying other nice things[1], so perhaps they're just having a bad day with debugging a deadlock.
Go has many strengths, but for Rob Pike to claim that Go addresses concurrency for the modern CPUs better than Java is just clearly b.s. Doug Lea, Cliff Click, Brian Goetz, et al. addressed multicore before Go even existed. I call b.s. when I see it.
(The nearly cult-like mentality of some of Go programmers is really quite annoying.)
It goes deeper than that. The prime difference is in the stance: "Is concurrency a library or is it a built-in feature?". In Java, it is the former, whereas in Go, it is the latter.
In my experience, having concurrency primitives in the language tend to integrate better than having them in a library - for the simple fact it saves some space when writing and reading programs.
As for the choice of `java.util.concurrent` over goroutines it again depends on your stance. j.u.c provides you with some excellent high-level primitives on which to build concurrency. But these primitives are easy to build in Go with its concurrency primitives. Some, like `BlockingQueue<E>` or `Future<V>` are directly isomorphic to a channel or a simple goroutine/channel invocation respectively. It is a matter of opinion whether or not one should actually do these kinds of implementations themselves.
A more important difference, however, is that Java operates on Threads as the "smallest" primitive, whereas a goroutine is a light-weight "thread". That is, you can easily have tens of thousands of goroutines running, but you do probably not want the same amount of threads in a Java system. For that, you need stuff like kilim.
In my experience, I am a professional Erlang programmer, the ability to run extremely concurrent threads/processes is a game changer for much of the code you will be writing.
> The prime difference is in the stance: "Is concurrency a library or is it a built-in feature?". In Java, it is the former, whereas in Go, it is the latter.
Fully agree. But in case of Go, the language feature is non performant.
cd $GOROOT/src
grep -r Lock *
You are strongly motivating me to write Go channel semantics over Java's (nio) Selectors and j.u.c to demonstrate a point... (Don't. I've other things to do.)
I would not be surprised if it turned out to perform extremely well - and perhaps even outperform Go. On the other hand, performance is not everything when it comes to writing large software systems. Again, my Erlang experience is that even if we are "hellishly slow" because every message is a copy in Erlang, it doesn't matter. For large software systems it turns out that the architectural design is what is the driving factor to program speed. How fast you pass a message is only part of the whole thing.
The real question to ask is how good a language is for the large scale software design. Certainly Java has proven itself to be there. Go is still young, but it specifically targets some of the problems in the same area as well. In my experience, debugging and the ease of doing so is also very important. And I don't know much about how easily this is to do in Go.
If it didn't, the fault would be mine. A dip to unsafe and it is effectively as bare metal as Go.
> The real question to ask is how good a language is for the large scale software design...
Agreed. A comparison with Java at this point would be unfair given the massive investment made by the industry in tweaking of the platform over nearly 2 decades. I think Go is a very promising language.
One simply hopes that the leading lights of the language/industry do not stoop to making threadbare (npi;) claims of superiority over other, equally viable, languages. After all, "it's just code". (PL religious wars are entirely boring.)
> debugging
Go has very good profiling and data race [1] detection tools. As far as debugging goes, I'm in the printf school of debugging (even on Java) and so far so good, so I can not speak to that.
GDB has full support for Go now. So how easy debugging in Go is depends on your opinion of GDB, to some extent (the learning curve is steep but it's a powerful tool, IMO).
The GogC++ engineers programming the custom computing hardware running communicating over custom network hardware with custom network software disagree with your assessment that "architectural design" is all that matters to obtain performance. When your compute budget is around a billion dollars per year, constant factor speedups are highly relevant.
I would like to do that for kicks. What numbers would be interesting to look at in terms of benchmarking (throughput, response times, waiting times, etc.)?
> Go codebases by non experts are peppered with magical incantation (sleeps, etc.) to avoid the dreaded "all goroutines are sleep".
I'm confused. This is indicative of a deadlock, where no goroutine can make progress. Sleeps would mask the symptoms, yes, but would never actually solve a deadlock, the program would just do nothing for a longer period of time. What Go codebase(s) are you referring to?
> A concurrent Go program will likely behave differently given 2 bits (just 2 lousy bits) of difference in the object binary. (runtime.GOMAXPROCS(1) vs runtime.GOMAXPROCS(2)). Imagine someone touching those 2 bits in a "large codebase". It is practically impossible to do the same thing in a large Java codebase and fundamentally change the programs runtime behavior. (Happens all the time in Go.)
If you are trying to find a low number of bits, you can just use 0. GOMAXPROCS can be set via an environment variable, the function is just to override that value.
More to the point, I am convinced that you are wrong. You are saying that in a Java class file, there are no 2 bits I could change that would impact the behaviour of a program, and that is plainly false.
> It is very difficult to reason about a Go routine's behavior in a "large codebase" without global view and a mental model of the dynamic system e.g. which go routine is doing what and who is blocking and who is not.
I guess this could be true if you engineer a system where every goroutine depends on every other goroutine. But it isn't true for code I've seen. As an example, the http library in Go has a goroutine that accepts TCP connections, and a goroutine for every accepted TCP connection. This knowledge is not necessary to use it, and is not necessary if a different part of your program is using it, because it is exposed behind an abstraction (http.Handler). To paraphrase the OP, Go enables simple programming. It doesn't forbid bad programming.
> There is nothing, absolutely nothing, that you can do in Go that you can not do via libraries in Java.
> On the other hand, there are plenty of things you can do in Java that are simply impossible to do in Go.
Depending on what you mean by "do", I either agree with you, or think you are mistaken. If you mean things that you can syntactically write down, like a Giraffe is-a Animal, or an Apple is-a Fruit, then yes, that is impossible to write down in Go. If you mean a problem that can be solved in Java that cannot be solved in Go, then I think you are mistaken.
> Once we factor in the possibility for bytecode engineering, then Java is simply in another higher league as far as language capabilities are concerned.
Why is this in another league? You can use assembly from Go, meaning you can generate code and jump to it if you really want to. Not sure why this would be considered a special feature of Java, or even why you think Java pioneered this. Bytecode is just a portable assembly, but its just as portable to build per-platform assembly emitters (like compilers do).
> Most people who rag on Java are clearly diletantes Java programmers.
Right. That makes sense to me; no one who knows anything about Java would ever criticize it. Sarcasm aside, this demonstrates a fallacy in reasoning.
> If Go actually manages to be as effective as Java for concurrent programming at some point in the future
It isn't more effective now? News to me.
> when they fix the somewhat broken runtime
Sorry, remind me what this is referring to?
> It just works. (But it is "boring" because it's not bling anymore. Oh well, kids will be kids.)
This is dangerous thinking. This is the cry that the native programmers raised when Java was born. Try and keep that in mind.
The issue is actually impossible to fix without overhauling the entire language. It's impossible to garbage collect unboxed objects without being conservative.
Exactly. But conservative GC sounds like a dumb idea in the first place. Im not the expert these people designing these languages are, but i can not understand how memory leaks can ever be acceptable just because the probability of it seriously affecting you, is low (when on x64). Doesnt that just imply you can not use these types of languages in any mission critical context.
I must be wrong though: it seems Google is using it for parts of their infrastructure, and im assuming those are long running procceses. But what if the worst case scenario does happen? Are there workarounds? Monitor memory usage, and just restart? Can we force the runtime to free a certain resource?
What am i missing? How does this not completely destroy anu utility of these languages? Why do people put conservative gc in languages outside of the esoteric or academic context?
> Doesnt that just imply you can not use these types of languages in any mission critical context.
No more so than with C++. There is a relatively high probability of you having left a memory leak in an average C++ server.
> Monitor memory usage, and just restart?
That would work, and is probably a good idea for all servers anyways. I've seen apache take upwards of 60 gigs due to some misconfiguration, so monitoring memory utilization of your programs and alerting or automatically restarting is a good idea.
> What am i missing? How does this not completely destroy anu utility of these languages? Why do people put conservative gc in languages outside of the esoteric or academic context?
There isn't really a good reason as far as I can tell. The only advantages are that its much simpler to implement, particularly when you have C interop. You can annotate Go objects with types to do precise collection, but as soon as you pass them to C, a lot of guarantees the Go typesystem makes go out the window. Other than that, can't think of anything.
It is my understanding the chance of complications is lower on a 64 bit system. But it is very likely, that well crafted requests can make any server application written in Go, trigger this complication, and essentially result in a DOS attack.
I think it would be mindblowingly difficult to cause this DOS. If you think it possible, you can setup a demo on appengine. You even get to upload the source code, so you have that advantage, that you wouldn't ordinarily have.
Gist of the task at hand: you'd have to arrange for data passed into your target application to point to structures in memory, causing them to be pinned. Ideally, these structures should be big, to maximize impact of the attack. Further, you'd have to ensure that the data you passed in isn't garbage collected, as this would allow the target structures to be collected.
> > On the other hand, there are plenty of things you can do in Java that are simply impossible to do in Go.
> Depending on what you mean by "do" ...
Oh, I don't know, maybe dynamic code loading or secure sandboxing of code? For instance you can compile a custom Google Go without disk IO, but you can't have an app that loads plugins much less one where the app can do IO but the plugin can't.
These may not be the wisest or most useful of features for "systems" programming, but you have to admit that there are real things Java can do that Google Go cannot.
I think Google Go advocates put blinders on like agentS because if they actually objectively looked at the situation they would have the same thing to say as others do about Google Go: "meh".
> Oh, I don't know, maybe dynamic code loading or secure sandboxing of code? For instance you can compile a custom Google Go without disk IO, but you can't have an app that loads plugins much less one where the app can do IO but the plugin can't.
Sure you can. Spawn a child process with lower security privileges, and communicate over a pipe. It might require you to restructure to reduce chattiness, but on the other hand, you will be much less likely to expose yourself to security vulnerabilities than the Java "sandbox".
If the child process is written in Go, you can even use the -u compiler flag to only allow safe packages (i.e. no assembly, C, only packages explicitly marked as safe and pure Go). You can go even further, and mark package os unsafe, disallowing file system access altogether. Or do what (I suspect) Appengine does, and provide your own neutered implementation of package os/time/net/etc, and mark those as safe.
The Go playground is an example of this, btw. It merely streams stdout and stderr, but you could imagine doing other things with the sandboxed program.
> I think Google Go advocates put blinders on like agentS because if they actually objectively looked at the situation they would have the same thing to say as others do about Google Go: "meh".
I think you are falling prey to the same fallacy of false cause as your GP. "agentS likes Go, so he must not be objectively looking at the language". It is possible to objectively look at the language, and think it useful.
This is exactly what I was talking about. You can't even admit facts like that Java has dynamic loading and a security model and that Google Go does not. You're simply delusional in this respect.
It seems I wasn't clear enough; I apologize for the confusion. I fully admit that Java has dynamic loading and a security model and the Go does not.
I was responding to "you can't have an app that loads plugins much less one where the app can do IO but the plugin can't."; that is, I was merely providing a way to implement what you wanted (plugins that cannot do IO, in a host that can).
Like I said in my original post, "If you mean things that you can syntactically write down, like a Giraffe is-a Animal, or an Apple is-a Fruit, then yes, that is impossible to write down in Go." Similarly, it is impossible to dynamically load code, or enforce permissions at the runtime level (although implementations of this enforcement has historically been... buggy, to be charitable). I was attempting to show that the problem of having sandboxed plugins is solvable in Go.
The child process approach is viable, but in fairness you should note that shared address space provides efficiencies that the RPC approach does not. This approach is IMO quite interesting in context multi-core and certain problem domains, but as a general mechanism it is a 'hack'.
It is borderline fanaticism to insist on comparing Go to Java, and unfair to Go. Effective advocacy of Go should focus on its strengths (syntax) and not attempt to gloss over its inherent limitations. It is a capable and viable language within well defined limits. Java and JVM are in another league. Accept it and move on.
If a new 'headius' feels up to it, Go on JVM would be a very interesting new language for the JVM ...
> The child process approach is viable, but in fairness you should note that shared address space provides efficiencies that the RPC approach does not. This approach is IMO quite interesting in context multi-core and certain problem domains, but as a general mechanism it is a 'hack'.
As to the lack of a shared address space, I thought I had communicated that when I said "It might require you to restructure to reduce chattiness", but yes, there are performance advantages to having a shared address space.
You should note that there are security disadvantages to having a shared address space with a sandboxed plugin written in a relatively low-level language (bytecode). I won't post several links to exploits of the Java sandbox in the last year alone, but I am sure you can google for them.
This mechanism is most certainly not a hack. This is the approach that Chromium and the other multi-process browsers (all the modern ones?) use for sandboxing. It seems far more effective to me to push responsibility for security to the OS, rather than the language runtime.
> A full featured runtime reflection mechanism that does not drop "static info" on the floor
Package reflect is fully featured. It just requires you to have a value, or type to actually reflect upon. The tradeoff being that Go can do dead-code elimination and Java cannot. Same thing for Class.forName.
> @MetaInfo() ... Arguably not easy on the eye but necessary and enabling.
I think you are referring to annotations. Yes, Go doesn't have these on methods, functions, or types. But it has these for struct fields (tags); this gives you 90% of the functionality, without muddying up the syntax.
> Bytecode injest (beyond dynamic linking) -- the JVM is your oyster.
Sure. See my note about all of these points below.
> and related Instrumentation
Go has a CPU profiler, a memory allocation profiler. In tip, it has a data race detector. It can expose this data over an HTTP interface so you can profile a running server http://golang.org/pkg/net/http/pprof/.
> It is borderline fanaticism to insist on comparing Go to Java, and unfair to Go. Effective advocacy of Go should focus on its strengths (syntax) and not attempt to gloss over its inherent limitations. It is a capable and viable language within well defined limits. Java and JVM are in another league. Accept it and move on.
You continually give me solutions that are impossible to implement in Go, but not the corresponding problems. Like I said, there are things that are syntactically impossible to write down in Go. If you want me to give you a list of things that are impossible to do in Java, I can do that (structural typing, value types, methods on values, multiple top level definitions in a single file, first class functions, efficient array slicing come to mind). I have not done that because it is a nonsensical thing to do. That would be like me saying Javascript is superior to Java because Java does not have prototypical inheritance.
The only useful example I've heard is sandboxed plugins. That is a problem, not a solution. All the things you've listed are solutions. If you actually want to have a conversation about how to solve problems in Go, then list problems, not a laundry list of features that Java has that Go does not.
> If a new 'headius' feels up to it, Go on JVM would be a very interesting new language for the JVM ...
Why? If I want more performance than gc gives me, then I use gccgo. What would Go on the JVM give me?
Also, on an unrelated note, I find it a little sad and pathetic how both you and 0xABADC0DA have to resort to insults to get your point across.
>> and related Instrumentation
> Go has a CPU profiler, a memory allocation profiler. In tip, it has a data race detector. It can expose this data over an HTTP interface so you can profile a running server http://golang.org/pkg/net/http/pprof/.
It is canonically called "instrumentation" but that is not all that it is capable of doing. Have you actually ever used this feature of Java?
> Also, on an unrelated note, I find it a little sad and pathetic how both you and 0xABADC0DA have to resort to insults to get your point across.
?? When and where did I insult you? Pathetic, on the other hand, is an insult. I strongly take exception to that.
Are you kidding me? This post is so full of arrogance and brazen oversimplifications of both Java and Go, there is so little of actual value to even bother discussing.
It's almost like you don't realize that Java came out a decade before Go, or that you don't understand the power of Goroutines or the power of writing your own low-level concurrent code.
I'd hate for you to find out that java's concurrency primitives are probably implemented using the same constructs as goroutines and/or are available to devs in the sync package. (Feel free to write "thread"-safe data structures. Hell, if you'd wanted to complain about the lack of generics in that case, I'd have even joined you.)
Research, sure, but it doesn't ignore the last decade of practical experience writing programs. A programming language is a user interface. The theory isn't all that matters.
And yet I'm writing tons of code in it very quickly. I don't know how it missed HN, but Go also now powers Google's download infrastructure (Chrome, etc)
If only Scala compilation weren't so slow. This is a bit off topic, but I find the difference between Scala and Go to exemplify some of the fundamental tradeoffs in the languages.
Scala is certainly the more researchy language with an advanced type system, better type inference, and multi-paradigm. However, its compilation is horribly slow, programming styles vary wildly, and I find its tools e.g., SBT, to be underdeveloped.
On the other hand, Go has constrained features and complexity, while providing higher-level features like GC, first-class functions, and simple type-inference, along with excellent tools e.g., gofmt and the build system.
I don't want to imply that one is simply better than the other, but I have enjoyed working in Go much more than Scala.
True. I haven't played with Go, but the reason I like Scala (slow compiler and somewhat lacklustre tooling aside) is precisely because I have a lot of time and brainpower invested in JVM-based stuff. If and when I need a wicked fast systems programming language, I think Go might be on the agenda.
Time for honesty: What bullshit.
- Go codebases by non experts are peppered with magical incantation (sleeps, etc.) to avoid the dreaded "all goroutines are sleep". Of course "they are doing it wrong", but that is the germinal point.
- A concurrent Go program will likely behave differently given 2 bits (just 2 lousy bits) of difference in the object binary. (runtime.GOMAXPROCS(1) vs runtime.GOMAXPROCS(2)). Imagine someone touching those 2 bits in a "large codebase". It is practically impossible to do the same thing in a large Java codebase and fundamentally change the programs runtime behavior. (Happens all the time in Go.)
- It is very difficult to reason about a Go routine's behavior in a "large codebase" without global view and a mental model of the dynamic system e.g. which go routine is doing what and who is blocking and who is not. Pretty much defeats the entire point of "simple" concurrency, to say nothing of "scaling". Programming in Go's variant of cooperative multithreading is actually more demanding than preemptive multithreading. Cute little concurrency pet tricks aside, Go concurrent programming actually requires expert level experience. "You are doing it wrong". Of course. Point.
- There is nothing, absolutely nothing, that you can do in Go that you can not do via libraries in Java. Sure, the cute syntactic go func() needs to be replaced with method calls to the excellent java.util.concurrent constructs, but the benefits -- high performance, explicit-no-magic-code -- outweigh the cute factor in this "programmer's" book.
- On the other hand, there are plenty of things you can do in Java that are simply impossible to do in Go.
- Once we factor in the possibility for bytecode engineering, then Java is simply in another higher league as far as language capabilities are concerned. (Most people who rag on Java are clearly diletantes Java programmers.)
If Go actually manages to be as effective as Java for concurrent programming at some point in the future (when they fix the somewhat broken runtime) then the Go authors are permitted to crow about it. Until that day, go fix_the_runtime() and defer bs().
One thing that programming in Go has made me realize is just how awesomely Sun/Gosling, et al. hit that "practical programming" sweet spot. No wonder the modern enterprise runs on Java and JVM.
It just works. (But it is "boring" because it's not bling anymore. Oh well, kids will be kids.)