4 ms·

Why not ? Go binaries don't require a seperate vm/runtime. Theyre faster in some cases and Go has overall simpler to read code than Java. There is room enough

Why not ? Go binaries don't require a seperate vm/runtime. Theyre faster in some cases and Go has overall simpler to read code than Java. There is room enough for both languages.

kaba0 4y ago
The modern Java packaging also includes the runtime itself, there is not even a JRE anymore. And readability is somewhat subjective, Java is a really simple language, all the writer does is just method calls into various existing libraries. Since those didn’t get a chance to evolve yet with the upcoming virtual threads they are a bit longer at times. So all what left is opinionated in-language support vs library support, and it is not clear cut which is the winner. Java seems to allow finer control over the primitives of concurrency, so a library or another JVM language could build up a much better abstraction over the mechanism.
- Cthulhu_ 4y ago
  I think the differences would drop off significantly if one were to write Java while keeping the Go guidelines and proverbs in mind; that is, reduce or eliminate the amount of 3rd party libraries (you don't actually need a dependency injection / wiring framework for most applications, just instantiate your objects with dependencies by hand in your main method), reduce the amount of abstraction layers, don't try to be clever, stick with regular loops instead of Streams, etc etc.
  - kaba0 4y ago
    I agree, though do keep in mind that a complex framework like Spring doesn’t play in the same league as a typical go microservice in terms of what kind of application is getting written in them. But I really hope that the new, record-based, minimal boilerplate java style gets hyped up more and more, we really should prefer compile time metaprogramming instead of reflection-based solutions. (E.g. mapstruct is really cool!)

4 ms·

Why not ? Go binaries don't require a seperate vm/runtime. Theyre faster in some cases and Go has overall simpler to read code than Java. There is room enough

by IceWreck 4y ago

Why not ? Go binaries don't require a seperate vm/runtime. Theyre faster in some cases and Go has overall simpler to read code than Java. There is room enough for both languages.

kaba0 4y ago
The modern Java packaging also includes the runtime itself, there is not even a JRE anymore. And readability is somewhat subjective, Java is a really simple language, all the writer does is just method calls into various existing libraries. Since those didn’t get a chance to evolve yet with the upcoming virtual threads they are a bit longer at times. So all what left is opinionated in-language support vs library support, and it is not clear cut which is the winner. Java seems to allow finer control over the primitives of concurrency, so a library or another JVM language could build up a much better abstraction over the mechanism.
- Cthulhu_ 4y ago
  I think the differences would drop off significantly if one were to write Java while keeping the Go guidelines and proverbs in mind; that is, reduce or eliminate the amount of 3rd party libraries (you don't actually need a dependency injection / wiring framework for most applications, just instantiate your objects with dependencies by hand in your main method), reduce the amount of abstraction layers, don't try to be clever, stick with regular loops instead of Streams, etc etc.
  - kaba0 4y ago
    I agree, though do keep in mind that a complex framework like Spring doesn’t play in the same league as a typical go microservice in terms of what kind of application is getting written in them. But I really hope that the new, record-based, minimal boilerplate java style gets hyped up more and more, we really should prefer compile time metaprogramming instead of reflection-based solutions. (E.g. mapstruct is really cool!)