Comment by SamInTheShell
19 hours ago
I found Go memory issues easier to solve than Java issues. You can see an example with etcd used in Kubernetes. I had to enable performance profiling in etcd to identify why it was eating up all the memory. It led me to a specific partition of keys that tracked back to a specific object type in Kubernetes.
It was literally enabling a flag and running some commands to do some really quick exports.
Dealing with the JVM though, heap dumps are slow to process and the UI I had to download was very clunky. I don't know if there are better tools, but even if there are the path to just doing it isn't straight forward.
Observability on the JVM is second to none, especially with tools like JFR available for free. You can literally connect to a live JVM and introspect it.
The potential of Java/OOP died with Sun as far as I am concerned. =3
You might want to stay concerned, as you are more than 2 decades outdated then.
Don't let Googles necromancy fool you, most of the use-cases have been deprecated. Have a great day =3
Rule #23: Don't compete to be at the bottom, as you just might actually win.
The productivity the JVM provides is second to none, including observability and state of the art GCs.
And let's not kid ourselves, Rust and golang are OOP (minus inheritance).
Not sure why your opinion was buried, but Java Applets in the wild are rare these days. There is little Java offers not already covered by HTML5, wasm, and WebGL. Only naive student projects, and legacy systems cling to the ecosystem.
>state of the art GCs
That just isn't true, most of the Subscription Enterprise Performance Pack features are under a paid license by Oracle. The FOSS options are always slowly catching up, or not standards compliant enough for some commercial programs.
Being a sentient turnip, I probably wouldn't understand such things. Yet in general, 3rd party dependency injection into a design pattern should be considered a long-term variable cost. =3
Rule #3: popularity is not an indication of utility.