3 ms·

I think an important element in comparing Go to Java for webserver apps is language design. While Java 8 and Go's performance may be similar in small single-thr

I think an important element in comparing Go to Java for webserver apps is language design. While Java 8 and Go's performance may be similar in small single-threaded request handler benchmarks, Java's baseline design encourages the creation of lots of expensive runtime abstractions, and makes parallelism difficult. Go on the other hand encourages a minimum of abstractions and makes parallelism trivial. That means that the marginal cost of business logic is much higher in Java, in both response times (due to unnecessary serialization) and overall computation. Some of this can be averted by careful engineering, but Java definitely isn't a "pit of success" in this regard - the easiest thing to do is usually the wrong thing.

twic 9y ago
> Java's baseline design encourages the creation of lots of expensive runtime abstractions Abstractions yes, expensive, perhaps not. One of the nice things about Java is that the JIT can collapse a lot of abstraction at runtime. Not all of it, but a lot of it. I am skeptical about the idea that Java naturally guides programmers towards expensive abstractions. > and makes parallelism difficult Presumably, you mean something like "makes lightweight concurrency difficult, because all the backend APIs for database access etc are blocking", which is unfortunately true.
- sidlls 9y ago
  I think perhaps it's more of a "pure OO" approach than the language itself. I've seen plenty of Java and C++ code where there is one interface class for every concrete class, even when just one concrete class is ever implemented, for example. I've also seen cases where some "factory" pattern is force-fit into the architecture, and the objects it creates are kinda sorta related, but ought not be in code. It gets exponentially worse as more interfaces and more levels in a hierarchy are allowed. The compiler isn't always going to be able to collapse or elide these.
diebir 9y ago
The thing about Go I do not get is why somebody would go back to essentially C to develop modern code? The tools are lacking, the language features are lacking, the libraries are lacking, so why? Go is still garbage collected language, so in a sense it combines the most problematic features of C and Java.

twic 9y ago

> Java's baseline design encourages the creation of lots of expensive runtime abstractions Abstractions yes, expensive, perhaps not. One of the nice things about Java is that the JIT can collapse a lot of abstraction at runtime. Not all of it, but a lot of it. I am skeptical about the idea that Java naturally guides programmers towards expensive abstractions. > and makes parallelism difficult Presumably, you mean something like "makes lightweight concurrency difficult, because all the backend APIs for database access etc are blocking", which is unfortunately true.

sidlls 9y ago
I think perhaps it's more of a "pure OO" approach than the language itself. I've seen plenty of Java and C++ code where there is one interface class for every concrete class, even when just one concrete class is ever implemented, for example. I've also seen cases where some "factory" pattern is force-fit into the architecture, and the objects it creates are kinda sorta related, but ought not be in code. It gets exponentially worse as more interfaces and more levels in a hierarchy are allowed. The compiler isn't always going to be able to collapse or elide these.

diebir 9y ago

The thing about Go I do not get is why somebody would go back to essentially C to develop modern code? The tools are lacking, the language features are lacking, the libraries are lacking, so why? Go is still garbage collected language, so in a sense it combines the most problematic features of C and Java.