You still need to be an expert on the virtual machine to not have things blow up. It's another factor of a complex equation.
My last job had a group of admins that thought any Java app from the Apache Foundation was the solution. Whenever things went wrong, their solution was, "just up the max heap size!" However, they're admins and had no idea about the app and the users had no Java experience to actually suggest tuning the JVM.
Yes, this was an org issue and a failure of tech leadership, but nevertheless, the JVM was a point of failure.
Go has a runtime with a GC with a heap size, just like the JVM does. People will end up having to tune their Go runtime GC's parameters, too. Whether the runtime is executing compiled native code, or executing JITted bytecodes is of little relevance to the user.
What you're speaking to is the issues with a _separate_ VM process and a cultural thing with Java generally, not a VM in particular.
My understanding was that a golang program's heap size will automatically grow as needed, and later (eventually) shrink as memory goes unused.
Is this true of java? Is it possible to run a java program in a way where it is allowed to use up all of the system's heap if needed, but also plays nicely with other processes on the system (i.e. yields the memory back to the OS after it becomes unused)?
Maybe this has been improved in the last 10 years but heap management imho is one of the not-great things about the JVM when I was using it. What is happening is quite invisible to sysadmins used to monitoring traditional unix processes. To them it looks like a giant memory hog, non-cooperative, when in reality the program might only be using a small % of what top is showing allocated to the process.
The original JVM philosophy seemed to be to cohost a bunch of stuff in one monolithic JVM process, rather than run a bunch of separate communicating processes. And in fact this "container" philosophy is what the original J2EE servers operated with.
You still need to be an expert on the virtual machine to not have things blow up. It's another factor of a complex equation.
My last job had a group of admins that thought any Java app from the Apache Foundation was the solution. Whenever things went wrong, their solution was, "just up the max heap size!" However, they're admins and had no idea about the app and the users had no Java experience to actually suggest tuning the JVM.
Yes, this was an org issue and a failure of tech leadership, but nevertheless, the JVM was a point of failure.