181–190 of 373 posts
Earlier quoted context omitted.
It has nothing to do with that and more to do with that last time I tried it the start-up times for an app was multiple seconds on top of base start times. Given how often Android evicts apps that's something I'm not comfortable with shipping. Would love to use Clojure but it was definitely a show-stopper for us.
What did you use instead?
I keep seeing plenty of evidence that the JVM is indeed heavy. When I was working at a startup and we were running Solr on the JVM, it kept running out of memory and crashing. When I tried using Clojure I was irritated by the startup time of the REPL on the JVM. More evidence: http://stackoverflow.com/questions/13692206/high-java-memory... . If you want something light like Clojure and don't need any Java libs, try P…
Same thing with Clojure. It basically bootstraps the entire Clojure environment on each process start. The JVM itself starts up in tens of milliseconds.
I think there's an incentive with more dynamic languages to decompose your software into smaller bits. When the language gives you the ability to "script" that helps even more. You don't need to bundle everything into an uberjar, you can run things independently, and therefore you don't even need all of the sources locally, just what you need to do your particular bit of data processing. It's possible to do this with Java and multiple JVMs, but it's hard, the incentives aren't there. Unfortunately I don't have experience with Clojure in the large to say whether it helps make the JVM feel lighter, from my side projects it seems like it could but I don't know if the community is going that way. Lispy languages have different incentives since they let you build from the bottom up so well.
Well, I sure wish I knew how to make our Clojure dev server (`lein ring server`) take less than 2 minutes to start up on a 4 core i7 16GB MacBook Pro. Fortunately I typically only need to restart it when switching branches.
I, literally, had a party at work when we got our web app to three days of continuous uptime without an OOM error; nevermind that the early JIT (1.4 era) took 12+ hours to get "warmed up" and give peak performance.
Don't misunderstand me- java's horribleness has given me a pretty nice career so, for that, I love it. For the years and years of broken promises- (OSGi without running out of PermGen? lol) I hate it.
Java is not lightweight by any means; computers are just faster and have more memory.
What the hell is an HCMB? Nothing on DuckDuckGo, and nothing on Urban dictionary. I wish people would stop using acronyms before defining them.
What the hell is an HCMB? Nothing on DuckDuckGo, and nothing on Urban dictionary. I wish people would stop using acronyms before defining them.
Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…
I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faster than memory...
For comparison, a C++ wxWidgets 3.0 application isn't going to be much smaller than 10MB in release mode if you statically link it. Much as I hate to admit it, 10MB just isn't that big in an age of terabyte SSDs and systems with 32GB of RAM.
Earlier quoted context omitted.
While this is true in practice it can be hard. You don't always have control of what libs you are using and often finding lightweight alternatives to many libraries is hard to impossible. It is better once you get outside Java proper, but nearly all the alternative languages on the JVM tout access to the Java ecosystem as a plus which then brings back in all that pain.
> You don't always have control of what libs you are using Well that's true regardless of the language. If you're not making the decisions on the codebase, there can be all kinds of gnarly dependencies and practices that you have to adhere to. I agree that big legacy corps tend to have over cumbersome setups, but hey, at least it's not cobol. My advice is not to work for big legacy corps.