5 ms·

RAM is billed by the hour (or minute?) by cloud providers, and it’s 1GB per process, not 1GB total. If you’re running 20 virtual servers, that’s 20 GB. Moreover

RAM is billed by the hour (or minute?) by cloud providers, and it’s 1GB per process, not 1GB total. If you’re running 20 virtual servers, that’s 20 GB. Moreover, if you’re shipping a desktop app, it’s 1GB * number of licenses. Finally, the “it’s not worth tuning” argument proves my point—Java proponents will tell you that Java doesn’t need to consume that much memory—you just have to tune it, but no one tunes it because it’s too hard/not worth it.

miskin 7y ago
But this, of course, applies to every project in any language and is in no way limited to Java or OOP. It is always balance between delivering functionality now with some solution or later MAYBE better optimized. Then in round two, optimized solution may be harder to maintain and extend, or further optimization may be de-prioritized to some new functionality with higher business value. We all know it. You are trying to project your belief to all Java applications and this simply does not work. There are both good apps and not good apps and there are many metrics to evaluate "good".
- weberc2 7y ago
  It appears to be specific to Java. Other languages don’t seem to exhibit high memory usage with the same frequency or severity as Java, and that’s not because developers of other languages spend more time optimizing. If indeed this observed memory bloat is just a matter of poorly written Java apps, then that’s even more interesting. Why does it seem like Java has such a high incidence of poorly written apps relative to other languages? Is it OOP or some other cultural element?
  - sgift 7y ago
    > It appears to be specific to Java. Other languages don’t seem to exhibit high memory usage with the same frequency or severity as Java, and that’s not because developers of other languages spend more time optimizing. It's because Java has strict memory limits. The limit of a bad C++ app is your machines whole memory (in theory more), so most people never notice if an app continues to leak memory or has weird memory spikes where it needs ten GB instead of one for a minute before it goes back to normal. Java forces you to either look at it or go the lazy route and just allocate more RAM to the JVM. Whatever you choose, you at least have to acknowledge it, so people tend to notice.
    - cbsmith 7y ago
      > It's because Java has strict memory limits. Java doesn't have strict memory limits. Sun's JVM has a setting for maximum heap size, but there are of course lots of other JVM's, and there are lots of other ways to consume memory. > The limit of a bad C++ app is your machines whole memory (in theory more) Well, that depends. Most people run operating systems that can impose limits, and you can certainly set a maximum heap size for your C++ runtime that works similarly to Java's limit. You just don't tend to do it, because you're already explicitly managing the memory, so there's no reason for setting a generalized limit for your execution environment. > so most people never notice if an app continues to leak memory or has weird memory spikes where it needs ten GB instead of one for a minute before it goes back to normal It also helps that short running apps and forking apps tend to hide the consequences of a lot of memory leaks, and in the specific case of C++, where memory mismanagement is often a symptom or a cause of severe bugs, you tend to invest a lot of time up front on memory management.
  - cbsmith 7y ago
    > It appears to be specific to Java. Other languages don’t seem to exhibit high memory usage with the same frequency or severity as Java, and that’s not because developers of other languages spend more time optimizing. Clearly you haven't looked at the memory overhead in scripting languages. ;-) They generally have far more object overhead, but their runtimes are designed for a very different use case, so their base runtime tends to be simple and tuned for quick startup. There are JVMs designed for similar cases with similar traits. It's just not the common choice. > If indeed this observed memory bloat is just a matter of poorly written Java apps, then that’s even more interesting. Why does it seem like Java has such a high incidence of poorly written apps relative to other languages? Is it OOP or some other cultural element? Your prejudice is showing in the other possibilities you haven't considered: perhaps memory intensive apps are more likely to be written in Java than other languages? Perhaps Java is more often selected in cases where memory utilization isn't a significant concern? You can find a preponderance of poorly written apps in a lot of languages... JavaScript and PHP tend to be the butt of jokes due to their notoriety. Poorly written apps isn't a language specific phenomena. For a variety of reasons that don't involve memory (the design of the language, the thread vs. process execution model, the JIT'd runtimes, the market penetration of the language), as well as some that do involve memory (threaded GC offers a great opportunity to trade memory for faster execution), Java applications are often long running applications that execute in environments with comparatively vague memory constraints, and so the common runtimes, frameworks, libraries, and programming techniques, etc., have evolved to trade memory for other advantages. But if you look at what people do with Java in constrained memory environments, or even look at the hardware that Java has historically run on, you'll plainly see that what you are observing isn't intrinsic to the language.
  - miskin 7y ago
    Just have a look on outbreak of Electron apps. People choose to use language they know and with which they can deliver value effectively instead of C or assembler.
cbsmith 7y ago
Cloud providers generally don't charge for RAM independently of other resources like CPU... and RAM isn't generally purchasable in 1GB increments. Accordingly, shaving 1GB off all your runtimes won't save you much money. There are more recently developed exceptions to that rule: container packing & FaaS offerings like AWS Lambda. Unsurprisingly, this has lead to the emergence of Java runtimes, frameworks, and libraries that are significantly more miserly with their use of memory (and are also designed for faster start up times as well). That said, while a lot of people complain about their cloud bill, most places I've seen have payrolls and/or software licensing costs that make their cloud bill look like a rounding error. Sure, when you reach a certain size it is worth trying to squeeze out some extra ducats with greater efficiency, but more often than not, your efficiency concerns lie elsewhere. Saying "no one tunes it" was deliberately overstating the case. If "everyone thinks the JVM needs 1GB just to run", then yes, "no one tunes it". Neither statement is true, but they both likely reflect some people's context.
michaelmrose 7y ago
This is actually a very good point but I don't know how this breaks down exactly. Can you give an example of a virtual server suitable for go vs java and the respective price points from a common provider?

miskin 7y ago

But this, of course, applies to every project in any language and is in no way limited to Java or OOP. It is always balance between delivering functionality now with some solution or later MAYBE better optimized. Then in round two, optimized solution may be harder to maintain and extend, or further optimization may be de-prioritized to some new functionality with higher business value. We all know it. You are trying to project your belief to all Java applications and this simply does not work. There are both good apps and not good apps and there are many metrics to evaluate "good".

weberc2 7y ago
It appears to be specific to Java. Other languages don’t seem to exhibit high memory usage with the same frequency or severity as Java, and that’s not because developers of other languages spend more time optimizing. If indeed this observed memory bloat is just a matter of poorly written Java apps, then that’s even more interesting. Why does it seem like Java has such a high incidence of poorly written apps relative to other languages? Is it OOP or some other cultural element?
- sgift 7y ago
  > It appears to be specific to Java. Other languages don’t seem to exhibit high memory usage with the same frequency or severity as Java, and that’s not because developers of other languages spend more time optimizing. It's because Java has strict memory limits. The limit of a bad C++ app is your machines whole memory (in theory more), so most people never notice if an app continues to leak memory or has weird memory spikes where it needs ten GB instead of one for a minute before it goes back to normal. Java forces you to either look at it or go the lazy route and just allocate more RAM to the JVM. Whatever you choose, you at least have to acknowledge it, so people tend to notice.
  - cbsmith 7y ago
    > It's because Java has strict memory limits. Java doesn't have strict memory limits. Sun's JVM has a setting for maximum heap size, but there are of course lots of other JVM's, and there are lots of other ways to consume memory. > The limit of a bad C++ app is your machines whole memory (in theory more) Well, that depends. Most people run operating systems that can impose limits, and you can certainly set a maximum heap size for your C++ runtime that works similarly to Java's limit. You just don't tend to do it, because you're already explicitly managing the memory, so there's no reason for setting a generalized limit for your execution environment. > so most people never notice if an app continues to leak memory or has weird memory spikes where it needs ten GB instead of one for a minute before it goes back to normal It also helps that short running apps and forking apps tend to hide the consequences of a lot of memory leaks, and in the specific case of C++, where memory mismanagement is often a symptom or a cause of severe bugs, you tend to invest a lot of time up front on memory management.
- cbsmith 7y ago
  > It appears to be specific to Java. Other languages don’t seem to exhibit high memory usage with the same frequency or severity as Java, and that’s not because developers of other languages spend more time optimizing. Clearly you haven't looked at the memory overhead in scripting languages. ;-) They generally have far more object overhead, but their runtimes are designed for a very different use case, so their base runtime tends to be simple and tuned for quick startup. There are JVMs designed for similar cases with similar traits. It's just not the common choice. > If indeed this observed memory bloat is just a matter of poorly written Java apps, then that’s even more interesting. Why does it seem like Java has such a high incidence of poorly written apps relative to other languages? Is it OOP or some other cultural element? Your prejudice is showing in the other possibilities you haven't considered: perhaps memory intensive apps are more likely to be written in Java than other languages? Perhaps Java is more often selected in cases where memory utilization isn't a significant concern? You can find a preponderance of poorly written apps in a lot of languages... JavaScript and PHP tend to be the butt of jokes due to their notoriety. Poorly written apps isn't a language specific phenomena. For a variety of reasons that don't involve memory (the design of the language, the thread vs. process execution model, the JIT'd runtimes, the market penetration of the language), as well as some that do involve memory (threaded GC offers a great opportunity to trade memory for faster execution), Java applications are often long running applications that execute in environments with comparatively vague memory constraints, and so the common runtimes, frameworks, libraries, and programming techniques, etc., have evolved to trade memory for other advantages. But if you look at what people do with Java in constrained memory environments, or even look at the hardware that Java has historically run on, you'll plainly see that what you are observing isn't intrinsic to the language.
- miskin 7y ago
  Just have a look on outbreak of Electron apps. People choose to use language they know and with which they can deliver value effectively instead of C or assembler.

cbsmith 7y ago

Cloud providers generally don't charge for RAM independently of other resources like CPU... and RAM isn't generally purchasable in 1GB increments. Accordingly, shaving 1GB off all your runtimes won't save you much money. There are more recently developed exceptions to that rule: container packing & FaaS offerings like AWS Lambda. Unsurprisingly, this has lead to the emergence of Java runtimes, frameworks, and libraries that are significantly more miserly with their use of memory (and are also designed for faster start up times as well). That said, while a lot of people complain about their cloud bill, most places I've seen have payrolls and/or software licensing costs that make their cloud bill look like a rounding error. Sure, when you reach a certain size it is worth trying to squeeze out some extra ducats with greater efficiency, but more often than not, your efficiency concerns lie elsewhere. Saying "no one tunes it" was deliberately overstating the case. If "everyone thinks the JVM needs 1GB just to run", then yes, "no one tunes it". Neither statement is true, but they both likely reflect some people's context.

michaelmrose 7y ago

This is actually a very good point but I don't know how this breaks down exactly. Can you give an example of a virtual server suitable for go vs java and the respective price points from a common provider?