A lot of folks seem to like the fact that Clojure runs on JVM. It solves the libraries problem and takes advantage of probably the best implementation of VM available. But unfortunately that guarantees that Clojure will never be truly mainstream.
Why? Lack of shared libraries. This is why Java itself failed. Look at the list of your processes: they all have significant number of code shared between each other. VM-based languages don't share anything [the only exception I'm aware of is ngen-ed assemblies in .NET]. If you rewrite all your running processes in Java you RAM consumption will go through the roof. Or perhaps even rewriting openssl in Java will double memory consumption of all processes that use it. Python/Ruby are little better because most of their standard libraries are implemented in C so at least two Ruby processes share the same implementation of printf.
In short, that's probably the biggest reason why VM-based languages can't come close to replacing various dialects of C on OSX/Linux/Windows: they don't play nice with the OS they're running on.
And needless to say, I would LOVE Clojure to become such replacement.
This brings me to a little dream: wouldn't be nice if Linux had a JVM-based userspace which would run all Java programs inside of just one big POSIX process, separated only by means of JVM without kernel involvement? Microsoft uses does something similar inside of IIS to host separated "application domains" for different web sites hosted by that IIS instance. If Linux did that, it would solve the following issues:
* Shared code!!! Loading a library once will guarantee that generated bytecode will be shared by all in-memory programs that use it. I.e. starting a 2nd instance of any Java program will eat zero plus process-specific local data.
* Instant startup times (JVM is loaded and all images can be pre-cached avoiding code validation). Caching of validated bytecode in a dump image AKA CL images is already a feature of JVM AFAIK.
* Seamless interop between processes since they're all running under the same garbage collector and share the same type system.
* Vastly increased productivity for desktop software programming. Not having to use dialects of C is awesome.
</dream>
BTW I heard of Microsoft's "Singularity" project which looks something like this, but for .NET. I wonder where are they going with it...
Java is popular for server-side applications, where one program runs on a cluster of machines. The RAM consumption issue arises on the desktop, where lot's of apps run on a single computer... and Java didn't get much market on the desktop.
It's also a very informative flame war. A amazing breadth of interesting topics are brought up and by message 250, most of individuals agree that Clojure is a very serious and quite brilliant Lisp.
Why? Lack of shared libraries. This is why Java itself failed. Look at the list of your processes: they all have significant number of code shared between each other. VM-based languages don't share anything [the only exception I'm aware of is ngen-ed assemblies in .NET]. If you rewrite all your running processes in Java you RAM consumption will go through the roof. Or perhaps even rewriting openssl in Java will double memory consumption of all processes that use it. Python/Ruby are little better because most of their standard libraries are implemented in C so at least two Ruby processes share the same implementation of printf.
In short, that's probably the biggest reason why VM-based languages can't come close to replacing various dialects of C on OSX/Linux/Windows: they don't play nice with the OS they're running on.
And needless to say, I would LOVE Clojure to become such replacement.
This brings me to a little dream: wouldn't be nice if Linux had a JVM-based userspace which would run all Java programs inside of just one big POSIX process, separated only by means of JVM without kernel involvement? Microsoft uses does something similar inside of IIS to host separated "application domains" for different web sites hosted by that IIS instance. If Linux did that, it would solve the following issues:
* Shared code!!! Loading a library once will guarantee that generated bytecode will be shared by all in-memory programs that use it. I.e. starting a 2nd instance of any Java program will eat zero plus process-specific local data.
* Instant startup times (JVM is loaded and all images can be pre-cached avoiding code validation). Caching of validated bytecode in a dump image AKA CL images is already a feature of JVM AFAIK.
* Seamless interop between processes since they're all running under the same garbage collector and share the same type system.
* Vastly increased productivity for desktop software programming. Not having to use dialects of C is awesome.
</dream>
BTW I heard of Microsoft's "Singularity" project which looks something like this, but for .NET. I wonder where are they going with it...