3 ms·

Trouble with java is that it does not scale up or down in terms of ram. Minimum RAM for a sever doing something normal over tcp is measured in gigabytes. Big

Trouble with java is that it does not scale up or down in terms of ram. Minimum RAM for a sever doing something normal over tcp is measured in gigabytes. Big servers > 16gb get difficult to manage at runtime. You have to scale with more VMs. You can write useful C servers that are very small, especially if you compile with musl. And run the same code for 1000kcc (not a typo) When you have big arrays of memory storing everything as Objects/pointers gets messy and inefficient. But any big heap is hard to manage and keep response times consistently low. My other gripe os that "write once run anyway" is no longer close to true, since Oracle. Mac, Linux x64 and Windows 64 are your only sane options. If you look at the compile targets list for c or rust you can see write once run anywhere working on a lot more cpus. True, you might have Arch specific code but it works, and most Java does not port from Linux container to Windows for example. A statically compiled Binary is often easier to move across systems, because a java app is rarely a single jar. It's usually >5gb of app specific jvm and libs and config files.

Dracophoenix 4y ago
kcc in this context is "kilo clock cycles", right?
ElectricalUnion 4y ago
> Trouble with java is that it does not scale up or down in terms of ram. > When you have big arrays of memory storing everything as Objects/pointers gets messy and inefficient. But any big heap is hard to manage and keep response times consistently low. Java can handle very large, TB-sized heaps (under normal circunstances, about 52TB). But when you're dealing with TB-sized heaps, anything is slow - including programs not made in Java. > You can write useful C servers that are very small, especially if you compile with musl. And run the same code for 1000kcc (not a typo) Anyone can build stuff with musl, but musl is in general a lot less optimized that GNU glib, so I guess it really only makes sense on resource-constrained environments - not those where you're handling TBs of heap. > A statically compiled Binary is often easier to move across systems I guess you're talking about jart/cosmopolitan here, not your average musl application - a statically compiled Binary usually needs to be recompiled to work on other systems. > because a java app is rarely a single jar. Uberjars are very common, the norm those days. > It's usually >5gb of app specific jvm and libs and config files. On my experience even if you "accidentally" bundled the whole Java SDK together with your app, you're not getting over 250MB for Java. Unless you're counting the whole OS, in that case, even the musl application isn't that small anyways.
- teknopaul 4y ago
  When I say move across systems, I mean from vm to vm not from lin to win. While a .class file will technically run on any jvm. A java application is usually more complicated and Uber jars don't work if you have stuff in meta-inf e.g. Spring. I am primarily a java dev and I have no tools or own code that run with java -jar some.jar.
  - ElectricalUnion 4y ago
    > While a .class file will technically run on any jvm. Not really, JDK 11 and further finally started removing deprecated implementation details, so you can't really run any class on any JVM - you ideally lockstep development and production JDK versions. > A java application is usually more complicated and Uber jars don't work if you have stuff in meta-inf e.g. Spring. This is more about the java application being complicated, and messing up with JAR metadata, not about stuff "not working"; in my experience, uber-jars built by Spring Boot "just work". > I am primarily a java dev and I have no tools or own code that run with java -jar some.jar. Most of my deployments were fleets of Spring Boot based services deployed with Containers with `RUN java -jar /app/my-project-name-1.0-RELEASE.jar`
Scarbutt 4y ago
Minimum RAM for a sever doing something normal over tcp is measured in gigabytes. wut? do you mean MB? most small web services(jetty, jdbc/pg driver/json) I have work on use below 500MB
KronisLV 4y ago
> Minimum RAM for a sever doing something normal over tcp is measured in gigabytes. Some of my Java services run with around 256-512 MB of RAM per instance, in Spring Boot containers (though Quarkus and Dropwizard can be even more conservative outside of enterprise bloat situations). That said, I'm inclined to agree in general, as I've seen monolithic Spring applications that refuse to run with anything less than 2-4 GB of RAM given to them. Perhaps even worse yet, there's no way for you to properly cap the resource usage within containers so you'd end up with more aggressive GC inside of containers but without OOM issues, when they're given a memory limit. -Xmx regularly gets exceeded because that's only a part of the equation and the creators of JVM didn't really think of a case where you should be able to give the whole thing a number of MB/GB it's allowed to use, which would never be exceeded, whatever it takes. > My other gripe os that "write once run anyway" is no longer close to true, since Oracle. Mac, Linux x64 and Windows 64 are your only sane options. Agreed, then again with most "business" software running in x86 OCI containers seems like the only sane option. Though I guess it depends on the environment that people have grown accustomed to and how they've been burnt in the past (e.g. I'd never want to use package managers or worse yet, extract random tar/zip archives for "business" software, never install Tomcat on the system directly etc., only use containers that are 1:1 the same in all environments where they're run). Of course, web dev is just a part of the greater picture, so there's lots of nuance there as well. Personally, SIM cards running Java seems like insanity to me, though: https://en.wikipedia.org/wiki/Java_Card https://en.wikipedia.org/wiki/Java_Card Then again, I'd say the same about Python implementations that are geared towards embedded setups, personally even Go seems like a better fit if someone didn't want to use C/C++/Rust, though platform support would still be a relevant question.

Dracophoenix 4y ago

kcc in this context is "kilo clock cycles", right?

ElectricalUnion 4y ago

> Trouble with java is that it does not scale up or down in terms of ram. > When you have big arrays of memory storing everything as Objects/pointers gets messy and inefficient. But any big heap is hard to manage and keep response times consistently low. Java can handle very large, TB-sized heaps (under normal circunstances, about 52TB). But when you're dealing with TB-sized heaps, anything is slow - including programs not made in Java. > You can write useful C servers that are very small, especially if you compile with musl. And run the same code for 1000kcc (not a typo) Anyone can build stuff with musl, but musl is in general a lot less optimized that GNU glib, so I guess it really only makes sense on resource-constrained environments - not those where you're handling TBs of heap. > A statically compiled Binary is often easier to move across systems I guess you're talking about jart/cosmopolitan here, not your average musl application - a statically compiled Binary usually needs to be recompiled to work on other systems. > because a java app is rarely a single jar. Uberjars are very common, the norm those days. > It's usually >5gb of app specific jvm and libs and config files. On my experience even if you "accidentally" bundled the whole Java SDK together with your app, you're not getting over 250MB for Java. Unless you're counting the whole OS, in that case, even the musl application isn't that small anyways.

teknopaul 4y ago
When I say move across systems, I mean from vm to vm not from lin to win. While a .class file will technically run on any jvm. A java application is usually more complicated and Uber jars don't work if you have stuff in meta-inf e.g. Spring. I am primarily a java dev and I have no tools or own code that run with java -jar some.jar.
- ElectricalUnion 4y ago
  > While a .class file will technically run on any jvm. Not really, JDK 11 and further finally started removing deprecated implementation details, so you can't really run any class on any JVM - you ideally lockstep development and production JDK versions. > A java application is usually more complicated and Uber jars don't work if you have stuff in meta-inf e.g. Spring. This is more about the java application being complicated, and messing up with JAR metadata, not about stuff "not working"; in my experience, uber-jars built by Spring Boot "just work". > I am primarily a java dev and I have no tools or own code that run with java -jar some.jar. Most of my deployments were fleets of Spring Boot based services deployed with Containers with `RUN java -jar /app/my-project-name-1.0-RELEASE.jar`

Scarbutt 4y ago

Minimum RAM for a sever doing something normal over tcp is measured in gigabytes. wut? do you mean MB? most small web services(jetty, jdbc/pg driver/json) I have work on use below 500MB

KronisLV 4y ago

> Minimum RAM for a sever doing something normal over tcp is measured in gigabytes. Some of my Java services run with around 256-512 MB of RAM per instance, in Spring Boot containers (though Quarkus and Dropwizard can be even more conservative outside of enterprise bloat situations). That said, I'm inclined to agree in general, as I've seen monolithic Spring applications that refuse to run with anything less than 2-4 GB of RAM given to them. Perhaps even worse yet, there's no way for you to properly cap the resource usage within containers so you'd end up with more aggressive GC inside of containers but without OOM issues, when they're given a memory limit. -Xmx regularly gets exceeded because that's only a part of the equation and the creators of JVM didn't really think of a case where you should be able to give the whole thing a number of MB/GB it's allowed to use, which would never be exceeded, whatever it takes. > My other gripe os that "write once run anyway" is no longer close to true, since Oracle. Mac, Linux x64 and Windows 64 are your only sane options. Agreed, then again with most "business" software running in x86 OCI containers seems like the only sane option. Though I guess it depends on the environment that people have grown accustomed to and how they've been burnt in the past (e.g. I'd never want to use package managers or worse yet, extract random tar/zip archives for "business" software, never install Tomcat on the system directly etc., only use containers that are 1:1 the same in all environments where they're run). Of course, web dev is just a part of the greater picture, so there's lots of nuance there as well. Personally, SIM cards running Java seems like insanity to me, though: https://en.wikipedia.org/wiki/Java_Card https://en.wikipedia.org/wiki/Java_Card Then again, I'd say the same about Python implementations that are geared towards embedded setups, personally even Go seems like a better fit if someone didn't want to use C/C++/Rust, though platform support would still be a relevant question.