It means installing a big runtime they aren't familiar with, and getting their feet wet with a huge ecosystem which spans from weird stacktraces to the standard libraries and beyond, and is associated (somehow wrongly) with boring code and old enterprise solutions.
Clojure stack traces are usually long and somewhat leaky, they are hard to read without (and sometimes even with) preexisting knowledge about Java / JVM / Clojure implementation details.
On the other hand, with some Java/JVM knowledge, they are very helpful. Whenever I come across supposedly nice error messages in most other languages, I'm convinced more and more that stacktraces are one of the right ways to do it...
Actually that is not true, Ruby stack traces are beautiful. Recently i saw a feature called "Did you Mean?" Have you ever seen such a stack trace in any other language? Clojures Stack traces are unreadable. My strategy with clojure debugging is usually commenting code and println thats how bad stack traces are in clojure but the thing is Clojure as a language is very thoughtful and thought provoking much more than any scheme i have seen. And certainly more enjoyable to code in than Ruby.
Folks at-least comment with a good reason before giving negative points for a comment. It helps clarify how the message was received a negative point without a comment is quite pointless and banal.
I am not sure how do i explain this, but a lot of people think about JVM with verbose slow VM code that works in the enterprise. java binary doesnt even follow unix styled cli options. the worded cli options are single hyphenated. There are many oddities associated with JVM/Java which are purely superficial. But yet a lot of people think it is irritation to use JVM, plus the perceived notion of Enterprise bloatware.
I get it, I make broad aesthetic choices about my technology too. Especially to avoid picking up an ecosystem I'd otherwise get to avoid ... so I'll add my own sterotypes.
Aren't all those crticisms double for Ruby? And Node?
You're adding a runtime, a package manager, and packages to your system with all three but two of them are just raw source code ...
> a lot of people think about JVM with verbose slow VM code that works in the enterprise
They are severely misinformed, then, and it would be a good deed to give them an opportunity to learn more about this.
Which is: Java is fast. Its startup time is impressive, and the runtime performance is generally also good. RAM usage could be less impressive, but I read that it can be optimized for memory consumption, achieving pretty good results - I don't have any experience here, so I can't really say.
Anyway, my problem with Java, is that it is not designed to be used on its own. To use it, you need a build system, and the language doesn't give you one; which is why there are many different systems, which you need to navigate somehow. Having to learn these build system (XML? custom Groovy implementation?) is what made me dislike Java. It's not that different in C++ or C#, but it adds to the feeling that you work with an ancient technology, not a modern one.
That's however not the problem with Clojure - it at least has a single build system + package manager - Leiningen. To me, what disqualifies it, is the startup time of its REPL. Well, that's only because I have a luxury of not needing to do anything on the JVM - so I'm speaking from a position of a hobbyist polyglot programmer considering new languages to learn. I would probably reconsider if I had a job where JVM would be a must, but the specific language was not yet chosen (how probable that would be is another matter). Anyway, back on topic: I don't have Clojure on this machine, but last time I tried it, it took more than a second before the prompt appeared. That is slow even when considered on its own, but it borders ludicrous (speed) when compared with other Lisps, which seems to be the right frame of reference here. In that comparison, it's... Well, just to let you know how bad it is, Common Lisp and Chicken Scheme, two Lisps I do have on this machine, have startup (+ shutdown!) times like this:
-▶ time sbcl --eval "(exit)"
This is SBCL 1.4.6-1.fc28, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
sbcl --eval "(exit)" 0,00s user 0,00s system 94% cpu 0,006 total
-▶ time csi -e "(exit)"
csi -e "(exit)" 0,00s user 0,00s system 93% cpu 0,005 total
Now, two things:
1) I get it that "you're supposed to have a deamon process in the background, so you don't need to start that often", but this, in itself, is basically announcing surrender. In Common Lisp you're supposed to do the same, but not by necessity!
2) Yes, I tried alternative runtimes/implementations. Indeed, they are better. However, until they get, provably, 99% the same semantics as the reference implementation, they won't be adopted by any significant amount of people, which has enough of the drawbacks to make me not seriously consider using them. Anecdotally, last time I looked, I've seen lots of lein plugins for setting up projects with ClojureScript on the frontend and some (pure) Clojure Web framework on the backend. There has to be a reason behind that.
TLDR: Java is very fast, Clojure uses JVM in ways which are inherently slow on that VM, but refuses to honestly migrate to a more suitable platform, because of Java ecosystem, which is also a major selling point of the language.
At least, that's my understanding of the situation - if I'm wrong, I'd be happy to get corrected.
I understand, i too had the same apprehension about clojure/JVM before i used it. Though the startup time of clojure was slow, Java is anything but slow. The startup tie has improved quite a low in clojure the past few months, but leiningen is still a pain to use.
> TLDR: Java is very fast, Clojure uses JVM in ways which are inherently slow on that VM.
JVM is really not the best platform for hosting either dynamic languages or functional ones.
Heres the time taken by csi, clojure , racket , sbcl.
>> time csi -e "(exit)"
real 0m0.088s
user 0m0.020s
sys 0m0.027s
>> time clj -e "(System/exit 0)"
real 0m1.944s
user 0m3.272s
sys 0m0.253s
>> time racket -e "(exit)"
real 0m1.100s
user 0m0.503s
sys 0m0.296s
>> time sbcl --eval "(exit)"
real 0m0.060s
user 0m0.023s
sys 0m0.025s
Java might be fast once it's had time to warm up, but its startup time is impressive only in how excruciatingly slow it is.
I wrote a small utility program in Java recently. It was getting slower and slower as it grew, so I profiled it. It turned out the slow parts were every part - the first time that part executes. E.g. parsing the command line arguments was slow the first time, but fast if I did it a second time. Same for reading configuration files, opening sockets, etc. I assume this has to do with a combination of lazy class loading (which is slow) and the JIT compiler not being warmed up.
Unfortunately for Java (and its users), you rarely need to parse your arguments a second time, so you never get to experience the case where Java is fast. It needs to be fast the first time, and it's not.
> To use it, you need a build system, and the language doesn't give you one; which is why there are many different systems, which you need to navigate somehow. Having to learn these build system (XML? custom Groovy implementation?) is what made me dislike Java
This sounds a bit out of date, as the vast majority of builds these days are Gradle, and those that aren't are probably 99% Maven.
However your point stands in that in both cases the build technologies are fairly arcane - few people who use them understand them well and they do form significant pain points whenever you need to go beyond the simple uses.
Ruby is great but its VM is no match for JVM. Still a kid on the block recently started experimenting with JIT. Its a long way to go before YARV can come close to JVM Performance.
oh I knew, it's not about perf, it's about perspective. Kinda like python.. Last week I've read some physicist saying he stopped cpp after 15 years to write python. It was more human friendly to write python and few performant bits in C than dealing with cpp culture. I'm sure that's the same for Java.
