4 ms·
Totally agreed that java fails hard for use cases involving small, lightweight binaries that are low memory and fast to start. This is an area where golang shin
by sreque 8y ago
Totally agreed that java fails hard for use cases involving small, lightweight binaries that are low memory and fast to start. This is an area where golang shines on the other.
People are starting to experiment with AOT compilation via graal to make headroom in this space, but the techonology being used feels young, nascent, and experimental or immature:
https://medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692 https://medium.com/graalvm/instant-netty-startup-using-graal...
https://www.innoq.com/en/blog/native-clojure-and-graalvm/ https://www.innoq.com/en/blog/native-clojure-and-graalvm/
Interestingly most high-level runtimes also have slow startup, including python, ruby, and node.js, but java's feels worse because people seem to want to use heavyweight frameworks like spring or aspectj that absolutely murder startup time, that for instance generate bytecode on startup or use classpath scanning to discover dependencies.
- thermodynthrway 8y agoYeah it's a bad trade-off developers don't realize they're making sometimes. Spring is Gigantic. Application containers like Tomcat aren't much better. It's easy to write huge apps in Java that still perform well so there's not much pressure to modulize huge monolithic libraries. So we all just deal with the 200+ deep stack frames. Newer frameworks like Vert.X and Dropwizard address this pretty well. We have a fairly large Dropwizard project that still starts in ~5 seconds. Also some written in Spring MVC that take 2 minutes... Also, God AspectJ let's you create horrible abominations. And it feels like it was designed to encourage you to do so. A great example of why you shouldn't always use self modifying code even if it's easy to do.