4 ms·

For serious work, Java has a bigger list of features, both on the primitive side and the abstract, that let you handle a lot more use cases than Go simply becau

For serious work, Java has a bigger list of features, both on the primitive side and the abstract, that let you handle a lot more use cases than Go simply because Go doesn't have the tools for them. So long as you stay away from Spring Boot and Hibernate, Java doesn't have to be all about BeanFactories. (Funny aside - somehow, Google managed to turn Rust into abstraction hell: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/factory/factory_store_providers/src/main.rs https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...)

bborud 3y ago
But do you really need those features? Or is it just force of habit? Learning how to express oneself consistently and with no more fluff than is strictly needed is much harder than people think. I admire people who can solve complex problems by simple means. I'm not terribly impressed by people whose obsessions drive them to write code with low readability. What features does Java have, and Go lack, which represent a real problem? With emphasis on the word "real".
- c_crank 3y ago
  Being able to tune the JVM properties for GC lets you build a reliable RTOS in Java. Checked exceptions offer stronger guarantees of error handling. Generics (something they did add to Go after years) let you build reusable methods without relying on a ton of boilerplate. None of these features cause the indigestibility of the bloated Java frameworks.
  - bborud 3y ago
    I've written quite a bit of software that has to deliver consistent latency and low jitter in Java and that isn't easy to do. It usually comes with big limitations as to what you can do. It is not just a matter of "tuning" the GC properties. It takes a lot more than that. Java is no more suited for realtime applications than Go. I work a bit on industrial realtime systems that actually do make certain guarantees, and neither the JVM nor the Go runtime are anywhere near anything you would want to touch with a ten foot pole for those kinds of applications. And if by RTOS you mean "embedded" then no, Java isn't suitable for that either since the runtime is huge and it typically needs a bit of RAM headroom to work properly. Checked exceptions only guarantee that someone will have to write code that catches those exceptions. It does not come with any guarantee that they will do anything meaningful with them. You still have to make sure that errors are handled by having code review practices that ensure error handling. It is no more a guarantee that a checked exception will be handled properly than it is a certainty that errors returned from function calls in Go will be heeded. This is engineering reality vs academic fantasy. I kind of agree on generics although, as you point out, Go has generics now. That being said, when sensibly applied, you will spend more time using generic types (like collection types etc) than creating them. Generics is something one typically wants to use sparingly since writing generic code is a lot harder than people like to think. I've seen a few projects where the code ended up being extremely hard to reason about because someone went overboard with generics in the design. I don't know yet if Go's approach to generics is good. I haven't used it enough (I don't need it that often), and it doesn't exactly seem like people are going overboard using it. Yet. This is also the first time I've had someone make the argument that Go has more boilerplate than Java.
    - c_crank 3y ago
      There is actually military hardware out there that runs on the JVM and not Go. That's a far stronger argument for its viability. >This is also the first time I've had someone make the argument that Go has more boilerplate than Java. Typical Java code ends up with more boilerplate than Go. Java gives tools to avoid boilerplate, but these are never used applicably in the enterprise environment which has a thirst for standardization.
      - bborud 3y ago
        Actual examples of actual realtime systems where the JVM is used would be a strong argument. Vague references to usage in military hardware isn't. Neither Java nor Go are languages you'd pick for realtime systems that require sensible guarantees. And why on earth would you use whether they are suitable for RT systems as any sort of metric? It is like judging a spoon by how good it is at being a fork. > Typical Java code ends up with more boilerplate than Go. Java gives > tools to avoid boilerplate, but these are never used applicably in > the enterprise environment which has a thirst for standardization. So you miss generics, even though Go has generics, because it avoids boilerplate, but Java has more boilerplate than Go, so something something enterprise standardization or lack thereof? Uhm...
        c_crank 3y ago
        Here's a link I found about Java RTOS in military software: https://www.militaryaerospace.com/computers/article/16708321/aonix-hardrealtime-java-technology-useful-for-command-and-control https://www.militaryaerospace.com/computers/article/16708321.... >So you miss generics, even though Go has generics, because it avoids boilerplate, but Java has more boilerplate than Go, so something something enterprise standardization or lack thereof? Java itself forces a limited amount of boilerplate. J2EE and Spring Boot and Hibernate and Swagger force a lot of boilerplate. Using Go itself means writing a lot of boilerplate, regardless of what libraries are included.
        bborud 3y ago

bborud 3y ago

But do you really need those features? Or is it just force of habit? Learning how to express oneself consistently and with no more fluff than is strictly needed is much harder than people think. I admire people who can solve complex problems by simple means. I'm not terribly impressed by people whose obsessions drive them to write code with low readability. What features does Java have, and Go lack, which represent a real problem? With emphasis on the word "real".

c_crank 3y ago
Being able to tune the JVM properties for GC lets you build a reliable RTOS in Java. Checked exceptions offer stronger guarantees of error handling. Generics (something they did add to Go after years) let you build reusable methods without relying on a ton of boilerplate. None of these features cause the indigestibility of the bloated Java frameworks.
- bborud 3y ago
  I've written quite a bit of software that has to deliver consistent latency and low jitter in Java and that isn't easy to do. It usually comes with big limitations as to what you can do. It is not just a matter of "tuning" the GC properties. It takes a lot more than that. Java is no more suited for realtime applications than Go. I work a bit on industrial realtime systems that actually do make certain guarantees, and neither the JVM nor the Go runtime are anywhere near anything you would want to touch with a ten foot pole for those kinds of applications. And if by RTOS you mean "embedded" then no, Java isn't suitable for that either since the runtime is huge and it typically needs a bit of RAM headroom to work properly. Checked exceptions only guarantee that someone will have to write code that catches those exceptions. It does not come with any guarantee that they will do anything meaningful with them. You still have to make sure that errors are handled by having code review practices that ensure error handling. It is no more a guarantee that a checked exception will be handled properly than it is a certainty that errors returned from function calls in Go will be heeded. This is engineering reality vs academic fantasy. I kind of agree on generics although, as you point out, Go has generics now. That being said, when sensibly applied, you will spend more time using generic types (like collection types etc) than creating them. Generics is something one typically wants to use sparingly since writing generic code is a lot harder than people like to think. I've seen a few projects where the code ended up being extremely hard to reason about because someone went overboard with generics in the design. I don't know yet if Go's approach to generics is good. I haven't used it enough (I don't need it that often), and it doesn't exactly seem like people are going overboard using it. Yet. This is also the first time I've had someone make the argument that Go has more boilerplate than Java.
  - c_crank 3y ago
    There is actually military hardware out there that runs on the JVM and not Go. That's a far stronger argument for its viability. >This is also the first time I've had someone make the argument that Go has more boilerplate than Java. Typical Java code ends up with more boilerplate than Go. Java gives tools to avoid boilerplate, but these are never used applicably in the enterprise environment which has a thirst for standardization.
    - bborud 3y ago
      Actual examples of actual realtime systems where the JVM is used would be a strong argument. Vague references to usage in military hardware isn't. Neither Java nor Go are languages you'd pick for realtime systems that require sensible guarantees. And why on earth would you use whether they are suitable for RT systems as any sort of metric? It is like judging a spoon by how good it is at being a fork. > Typical Java code ends up with more boilerplate than Go. Java gives > tools to avoid boilerplate, but these are never used applicably in > the enterprise environment which has a thirst for standardization. So you miss generics, even though Go has generics, because it avoids boilerplate, but Java has more boilerplate than Go, so something something enterprise standardization or lack thereof? Uhm...
      - c_crank 3y ago
        Here's a link I found about Java RTOS in military software: https://www.militaryaerospace.com/computers/article/16708321/aonix-hardrealtime-java-technology-useful-for-command-and-control https://www.militaryaerospace.com/computers/article/16708321.... >So you miss generics, even though Go has generics, because it avoids boilerplate, but Java has more boilerplate than Go, so something something enterprise standardization or lack thereof? Java itself forces a limited amount of boilerplate. J2EE and Spring Boot and Hibernate and Swagger force a lot of boilerplate. Using Go itself means writing a lot of boilerplate, regardless of what libraries are included.
        bborud 3y ago