> 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 mess

> 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.