Hacker News Reader

Comment by pankajdoharey | Hacker News Reader

GraalVM is very impressive. But clojure is very much associated with Java/JVM Ecosystem which makes it very hard to convince people to use it. My ruby friends would say oh i cant install clojure because i have to install JVM. Clojurescript like lumo or planck is still better, but it isnt a real backend solution. Clojurescript is great for the frontend though. I think clojure needs a native solution written in Clojure + LLVM that leverages existing C-libs. A seperate JIT/compiler that is not JVM, that is not a language with Borrowed GC + VM.

View on HN

I love Clojure. The JVM is a catch-22 for the language. Clojure is as successful as it is thanks to the huge JVM ecosystem. But it's true that some (a lot?) of folks won't try it, due to suspicion of Oracle, hatred of Java culture, perceived bloatiness of the JVM, etc.

I know a senior dev who loves Ruby and Elixir and won't consider touching anything in the Java ecosystem ever again after a terrible experience at a government consulting company.

So yeah. I think the best shot I have at convincing him to try it is to point him to something like Clojerl: https://github.com/clojerl/clojerl

Gotta love the close mindedness of developers.

I don't really get it.

If a customer needs to have something in some tech I dislike, then that is what I use, regardless of my opinion.

Whatever makes the customer happy comes first.

I wonder what that terrible experience was and how it could be so bad. After all I've had bad experiences with apps written in C, C++ and Python but I'd still use these tools when necessary. To write off something as huge as the JVM and its ecosystem because of one bad experience seems iffy.

I think the reality is there are a lot of people for whom hatred of anything Java is a fashion statement, a strange geek form of virtue signalling. Oracle is not significantly different to Microsoft or Apple after all - they are all companies that like money and have sued Android related companies over IP rights to obtain lots more of it. If anything Oracle's moral case is a lot stronger as Java represents a much greater investment than FAT32 or rounded rectangles or the other stuff these firms demanded ridiculous sums for. Yet hackers are just A-OK with praising and promoting VS Code, macOS, Swift, etc.

I don't personally mind. The more people who ignore the Java ecosystem for fashion related reasons, the more my competitors reduce their strength and relevance. If your senior dev friend is off writing code in Elixir and struggling with low performance VMs and tiny library ecosystems, I'll be outpacing them with better VMs, better tools and a huge ecosystem of open source libraries. No problem!

I don't understand this sentiment. How is installing JRE any diffierent than installing Ruby?

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.

The almost exact same could be said for Ruby and frankly, any other programming language which has stacktraces and a standard library.

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.

https://ioavisopretty.readthedocs.io/en/v0.1.34/exceptions.h...

https://lispcast.com/clojure-error-messages-accidental/

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...

Clojure error messages are on slate for improvement in 1.10, though: https://mobile.twitter.com/puredanger/status/102810365424144...

Platform details are eventually going to leak, regardless of which one gets targeted.

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

>> time newlisp -e "(exit)"

real 0m0.089s user 0m0.011s sys 0m0.033s

Clojure is the slowest in this.

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.

java is a behemoth~, ruby is human sensible

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.

we are talking about the platform - the JVM - not the Java language. You can run Python, Ruby, JS, Clojure etc. on the JVM apart from Java.

It's important to remember that the JVM alone is a huge community. The fact that a lot of Ruby people don't understand the value of the JVM is really their own problem. The JVM is a far better runtime than any of the Ruby VMs, and it has a much better story when it comes to dependency management and packaging.

I don't actually see much value in having Clojure on LLVM as you'd have to build a whole ecosystem from scratch instead of being able to rely on the mature existing ecosystem that the JVM provides.

Actually the JVM is one of the reasons I would recommend clojure. It's a fine piece of engineering; much more solid than most VMs out there. Lots of tools for perf/monitoring/debugging.

Why would you require an existing C lib? These days you have lots of JVM apps doing heavy lifting: from bigdata stuff (hadoop, presto, kafka, others) to webapp stuff (undertow, check techempower benchmarks). For those special cases you can wrap a C lib with FFI, but in my 10+ years of JVM experience I only needed to do it once, and it was because I was streaming video on a jnlp (java swing/java web start) app which worked remarkably well, considering I supported windows,linux and mac.

It's actually much harder to convince someone to use Ruby or Clojure rather than Java, especially in enterprise projects.

Graal is able to produce native, statically linked executables that do not require a JVM installed to run. See the native-image component of Graal.

It will be fun if TruffleRuby becomes a popular Ruby VM. It sure does have a lot of potential, and they are working to pass all of Rails tests.

Thats Difficult, because DHH is against Java, and he refused to use JRuby. I dont see how people will adapt TruffleRuby when their supreme leader refuses to acknowledge any other ruby but MRI.

That's interesting. Did DHH write anything on the subject?I'd be curious to read it.

> friends would say oh i cant install clojure because i have to install JVM

It's interesting how in the software world people whom you'd expect to be entirely rational make decisions based on feelings and hearsay. I don't understand this.

I say "in the software world", because I see more objectivity in hardware design. Hardware engineers rarely black out entire technologies just because they don't feel like it.

Reply on news.ycombinator.com