3 ms·

> There is no client side jvm dependency anymore. You bundle the jvm as part of your executable So there is still a JVM dependency then, you're just hiding it.

> There is no client side jvm dependency anymore. You bundle the jvm as part of your executable So there is still a JVM dependency then, you're just hiding it. How does that JVM bundling work out for bloat ? I'm guessing it increases the size of the package, and the JVM still has a tendency to eat RAM for breakfast like it always did ? Does JVM still need "tuning" for production via obscure flags and XML file params ?

fulafel 4y ago
Go also embeds a copy of the runtime in the executable and has a reputation for big executable size.
matsemann 4y ago
Your argument was that go was "batteries included for the user", and I pointed out that's now true for java as well. Now you're moving the goal post. I don't really care about a few mb extra size of bundling. Maybe some use cases do. I haven't tweaked jvm params in years. For a dockerized cloud deploy it's fire and forget. If we're talking about bloat, the current python app I'm working on needs ~20x as many nodes as a similar jvm project I worked on earlier..
erik_seaberg 4y ago
Tuning the JVM is no fun, but tuning by repeatedly rewriting your own code is a lot more effort and risk. As for package size, there are people who bundle a stripped down JVM with a single app, but I don’t think that’s a good use of time—I’d much rather declare a dependency on the complete OpenJDK, and rely on the system package manager to install exactly one copy of it for all apps to use.
willnonya 4y ago
I am not familiar with GO but it seems a fallacy to believe that any language not already integrated with the OS wouldn't have some dependency that has to be installed or included in the distrusted files for them to work. Your other comments seem to fall into the mindset of those that think that being able to control or configure your environment is somehow bad because it requires you to know something about that environment.

fulafel 4y ago

Go also embeds a copy of the runtime in the executable and has a reputation for big executable size.

matsemann 4y ago

Your argument was that go was "batteries included for the user", and I pointed out that's now true for java as well. Now you're moving the goal post. I don't really care about a few mb extra size of bundling. Maybe some use cases do. I haven't tweaked jvm params in years. For a dockerized cloud deploy it's fire and forget. If we're talking about bloat, the current python app I'm working on needs ~20x as many nodes as a similar jvm project I worked on earlier..

erik_seaberg 4y ago

Tuning the JVM is no fun, but tuning by repeatedly rewriting your own code is a lot more effort and risk. As for package size, there are people who bundle a stripped down JVM with a single app, but I don’t think that’s a good use of time—I’d much rather declare a dependency on the complete OpenJDK, and rely on the system package manager to install exactly one copy of it for all apps to use.

willnonya 4y ago

I am not familiar with GO but it seems a fallacy to believe that any language not already integrated with the OS wouldn't have some dependency that has to be installed or included in the distrusted files for them to work. Your other comments seem to fall into the mindset of those that think that being able to control or configure your environment is somehow bad because it requires you to know something about that environment.