4 ms·

At the minimum, the verbosity problem. We can argue that any language is less verbose and more concise than Java. Go is inherently not a OO language and has so

At the minimum, the verbosity problem. We can argue that any language is less verbose and more concise than Java. Go is inherently not a OO language and has some excellent functional constructs which makes it easy to approach and solve certain set of problems whereas in Java you are forced to do the OO way even if the problem at hand does not require that way of solving stuffs. Finally, Go compiles to machine code and I guess it should be way faster than Java.

riku_iki 8y ago
> Go compiles to machine code and I guess it should be way faster than Java. Java is also not interpreted for 20 years already. JIT compiler compiles jvm bytecode into machine code.
nostalgeek 8y ago
> At the minimum, the verbosity problem I don't believe a single second that Java is more verbose than Go. It's just that Go hasn't been buried under layers and layers of EE ...yet. In fact the whole "if err!=nil" boilerplate is the very definition of verbosity. > Go is inherently not a OO language Everytime you use interfaces you are doing OOP. And there is no choice but using interfaces when dealing with streams, which is 99% of what people use Go for. > has some excellent functional constructs No more than the latest Java. In fact Java has something Go definitely doesn't have which is pretty useful for functional programming: generics. > Finally, Go compiles to machine code and I guess it should be way faster than Java. AOT compilation is coming to Java.
- ihsw2 8y ago
  I have a hard time buying that EE cruft will creep into Go -- it specifically guards against inheritance/factory/DI hell by offering a unique type system (enforcement of clean interfaces between packages). If you try to implement Java-like design patterns in Go then you're going to have a bad time -- personally this is one of its strengths.
  - riku_iki 8y ago
    > it specifically guards against inheritance/factory/DI hell by offering a unique type system Many people, including Google engineers (https://github.com/google/guice https://github.com/google/guice) see DI as useful tool, not hell. But nothing prevents you to write your java code without DI if you don't like it.
    - smueller1234 8y ago
      DI is unquestionably, heavily used in Google code, including in Go code bases. Nonetheless, GPs point seems to be more along the lines that the type system helps avoid the horrible spaghetti of design patterns that many a Java project ails from. I'm not entirely sure about how much of that difference is a matter of culture vs. language and would love to see GP expand on their thoughts.
  - deleted 8y ago
    [deleted]
- geodel 8y ago
  > I don't believe a single second that Java is more verbose than Go. It's just that Go hasn't been buried under layers and layers of EE ...yet. In fact the whole "if err!=nil" boilerplate is the very definition of verbosity. You don't have to believe anything. But when I download JDK source I can clearly see tendency to over abstract since very early days when Java EE wasn't even a thing. I have worked on many Java projects where code was rejected because it did not use enough 'design patterns'. As a Java programmer the main win of Go I see that now I can write a few hundred lines of straight forward Java code in a single file which does some work. In past it would be dozens of class files spread over ten packages and 5 xml config files.
  - riku_iki 8y ago
    > now I can write a few hundred lines of straight forward Java code in a single file which does some work. What exactly prevented you to do this before?..

riku_iki 8y ago

> Go compiles to machine code and I guess it should be way faster than Java. Java is also not interpreted for 20 years already. JIT compiler compiles jvm bytecode into machine code.

nostalgeek 8y ago

> At the minimum, the verbosity problem I don't believe a single second that Java is more verbose than Go. It's just that Go hasn't been buried under layers and layers of EE ...yet. In fact the whole "if err!=nil" boilerplate is the very definition of verbosity. > Go is inherently not a OO language Everytime you use interfaces you are doing OOP. And there is no choice but using interfaces when dealing with streams, which is 99% of what people use Go for. > has some excellent functional constructs No more than the latest Java. In fact Java has something Go definitely doesn't have which is pretty useful for functional programming: generics. > Finally, Go compiles to machine code and I guess it should be way faster than Java. AOT compilation is coming to Java.

ihsw2 8y ago
I have a hard time buying that EE cruft will creep into Go -- it specifically guards against inheritance/factory/DI hell by offering a unique type system (enforcement of clean interfaces between packages). If you try to implement Java-like design patterns in Go then you're going to have a bad time -- personally this is one of its strengths.
- riku_iki 8y ago
  > it specifically guards against inheritance/factory/DI hell by offering a unique type system Many people, including Google engineers (https://github.com/google/guice https://github.com/google/guice) see DI as useful tool, not hell. But nothing prevents you to write your java code without DI if you don't like it.
  - smueller1234 8y ago
    DI is unquestionably, heavily used in Google code, including in Go code bases. Nonetheless, GPs point seems to be more along the lines that the type system helps avoid the horrible spaghetti of design patterns that many a Java project ails from. I'm not entirely sure about how much of that difference is a matter of culture vs. language and would love to see GP expand on their thoughts.
- deleted 8y ago
  [deleted]
geodel 8y ago
> I don't believe a single second that Java is more verbose than Go. It's just that Go hasn't been buried under layers and layers of EE ...yet. In fact the whole "if err!=nil" boilerplate is the very definition of verbosity. You don't have to believe anything. But when I download JDK source I can clearly see tendency to over abstract since very early days when Java EE wasn't even a thing. I have worked on many Java projects where code was rejected because it did not use enough 'design patterns'. As a Java programmer the main win of Go I see that now I can write a few hundred lines of straight forward Java code in a single file which does some work. In past it would be dozens of class files spread over ten packages and 5 xml config files.
- riku_iki 8y ago
  > now I can write a few hundred lines of straight forward Java code in a single file which does some work. What exactly prevented you to do this before?..