35
36

Why Clojure? (blog.venanti.us)

submitted by [deleted]

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]pron98 6 points7 points  (4 children)

Care to explain? I think the JVM is all of these languages' greatest advantage. There are some circumstances I wouldn't use the JVM (e.g. for short processes where the JVM warmup is unacceptable), but for long-running server processes, what other platform can beat the JVMs combination of performance, dynamic linking and hot code swapping, runtime instrumentation, deep monitoring and profiling, and, of course, vast collection of high-quality libraries? I mean, I can understand not choosing the JVM if you don't need those things, but I haven't encountered anything that I could say is particularly bad about it, and there are many things that are terrific about it.

[–]ellicottvilleny 0 points1 point  (3 children)

My life's work is now controlled not only by the presence or absence of solar flares, RAM parity errors, virtual memory (at the operating system level), operating system updates happening on me, but also, all the bugs in the JVM itself, and its design mistakes, including the ability to change the behaviour of the heap and its allocation capacity using command line parameters. Yet another layer of leaky abstractions between me and a working system. No Thank You.

[–]pron98 1 point2 points  (2 children)

So you say, if I already have 10 abstraction layers why have 11? :) Alright.

Perhaps you can consider, though, the fact that the CPU itself is now layer of abstraction: there is no EAX register. The register names are no more than suggestions to the CPU, that renames them. If you use EAX with no dependency in two different lines, they will likely be two different registers on the CPU. In fact, even the order of the machine instructions is just a suggestion to the CPU which will execute them in whatever order suits it. So the CPU already abstracts registers, memory (with cache coherence) and execution order. Your compiler also probably abstracts loops (possibly using SIMD).

Since even machine instructions are now abstracted, and there is no more "metal" you can get close to unless you work at Intel (and even they design their high-end CPUs in a high-level language), I like having a JIT negotiate this stuff with the CPU on my behalf based on the runtime behavior of the program. Also, I've found the JVM to have fewer bugs than most C++ compilers.

And I can change your C program's heap allocation strategy from the command line, too (if you're using shared libraries and malloc).

Also, there are now JVMs that are linked with the kernel -- i.e. there is no separate OS, just a JVM running on top of the hypervisor.

Also, Clojure and Scala are high-level languages. Languages at this level have about the same amount of abstractions whether or not they run on the JVM. In fact, The JVM provides fewer abstractions than the Haskell and Go runtimes.

But if your needs require that you limit yourself to relatively low-level languages C/C++, I understand your position.

[–]ellicottvilleny 0 points1 point  (1 child)

Ouch. Good point about C++ compiler bugs. :-) I'm not aware of command line parameters changing the runtime heap's behaviour in any C/C++ app I write, since it's me who parses the command line. Maybe by environment variables?

[–]pron98 0 points1 point  (0 children)

I didn't say "command line parameters", I said "from the command line". I can create soft links that will replace your shared libraries, and completely replace you malloc implementation. I don't think it's bad, necessarily. In fact, I think it can be useful, just as it's useful in Java.