4 ms·

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

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
    "here's a link I found"? So you made a claim, then you googled for things that might support your view, then posted them after skimming them? I don't think we need to discuss further.

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
  "here's a link I found"? So you made a claim, then you googled for things that might support your view, then posted them after skimming them? I don't think we need to discuss further.