3 ms·

You're arguing a lot of abstract points here but let's have a walkthrough... > I have used both in production likewise, and I have found the opposite stance f

You're arguing a lot of abstract points here but let's have a walkthrough... > I have used both in production likewise, and I have found the opposite stance for Java/JVM based applications. Terrible deployment story, terrible amount of tweaking and JVM "hacks". > Java is getting a green thread implementation by means of project Loom Well done to Java. It's getting features already commonplace in Golang. Bolting on Akka, Vertx... yeah, enjoy your frankensteins monster lol. > no generics Generics _arent_ critical for a language, exceptions are a mess and as for the JVM being state of the art... yeah. In the 90s it was. > The main reason for golang is the hype behind it I just fundamentally disagree - if that was truly the case, I'd have adopted Java back when it was hyped and relevant and would've moved onto Rust by now from Golang which never happened.

apta 7y ago
> Terrible deployment story, terrible amount of tweaking and JVM "hacks". A lot of people these days are building fat/uber jars. All it takes to run your code is `java -jar foo.jar`. Can't get much simpler than that. Tweaking is a plus that golang doesn't offer. The JVM runs an extremely wide range of workloads, and gives you the ability to tune it accordingly, e.g. whether you care more about throughput vs latency. Compared to golang where this is extremely limited. It's not surprising that a huge number of data processing workloads run on the JVM (regardless of implementation language). > Bolting on Akka, Vertx... yeah, enjoy your frankensteins monster lol. That's not an argument. These frameworks are mature and battle tested, not to mention built on sound principles (e.g. Akka is similar to Erlang's actor model, which includes supervisor capability and remoting - nothing like this exists in golang). > Generics _arent_ critical for a language, exceptions are a mess They're not critical in the same way "functions/procedures" are not critical, but you're going to end up with a messy code base when it comes to reality. Again, the number of times I've seen what amounts to map/filter calls littering the code base, making it more difficult to read (not to mention error prone) is too many to count. Generics fix this. Funnily enough, it's golang that chose to disregard best practices from the 70s. > and as for the JVM being state of the art... yeah. In the 90s it was. Tell that to Google, FB, Apple, Amazon, and many more who run their critical infrastructure on the JVM. The introspection and monitoring it provides is literally second to none, not to mention performance, tunability, hot-swapping, rich ecosystem, and many more. > I just fundamentally disagree You can, but the fact remains that some of the same authors worked on a golang predecessor which never went anywhere, precisely because it didn't have the Google name behind it.

apta 7y ago

> Terrible deployment story, terrible amount of tweaking and JVM "hacks". A lot of people these days are building fat/uber jars. All it takes to run your code is `java -jar foo.jar`. Can't get much simpler than that. Tweaking is a plus that golang doesn't offer. The JVM runs an extremely wide range of workloads, and gives you the ability to tune it accordingly, e.g. whether you care more about throughput vs latency. Compared to golang where this is extremely limited. It's not surprising that a huge number of data processing workloads run on the JVM (regardless of implementation language). > Bolting on Akka, Vertx... yeah, enjoy your frankensteins monster lol. That's not an argument. These frameworks are mature and battle tested, not to mention built on sound principles (e.g. Akka is similar to Erlang's actor model, which includes supervisor capability and remoting - nothing like this exists in golang). > Generics _arent_ critical for a language, exceptions are a mess They're not critical in the same way "functions/procedures" are not critical, but you're going to end up with a messy code base when it comes to reality. Again, the number of times I've seen what amounts to map/filter calls littering the code base, making it more difficult to read (not to mention error prone) is too many to count. Generics fix this. Funnily enough, it's golang that chose to disregard best practices from the 70s. > and as for the JVM being state of the art... yeah. In the 90s it was. Tell that to Google, FB, Apple, Amazon, and many more who run their critical infrastructure on the JVM. The introspection and monitoring it provides is literally second to none, not to mention performance, tunability, hot-swapping, rich ecosystem, and many more. > I just fundamentally disagree You can, but the fact remains that some of the same authors worked on a golang predecessor which never went anywhere, precisely because it didn't have the Google name behind it.