Note that you aren't tied to Java 8, which is quite old by now, but can also run GraalJS with OpenJDK 11, 12, 13, and enjoy the recent performance improvements to the GC (using ZGC or Shenandoah) and startup time (using Application CDS):
Native image is experimental, and I believe is a separate download now. Maybe someone from the Graal team can give more precise information about what exactly works in stock OpenJDK, but you should try that demo with Java 12 (or even 13). While you're at it, also give ZGC a try (see https://news.ycombinator.com/item?id=19886856 and http://www.programmersought.com/article/8311115057/).
We are working with a very high priority on JDK 11 support. We should be able to ship it in a few months from now.
> So is graal polyglot already compatible with newer JDKs and it's just native image generation that's blocking the upgrade?
Not just. We also need to upgrade the JVMCI version we use in order to support libgraal (Graal compiler as native-image in HotSpot). Also, modules make everything a little bit more complicated as well.
> we switched our production JVM to GraalVM, which opened a new possibility since it comes with GraalJS, a JavaScript engine which aims to compete with today's faster JavaScript engines like V8 and JavaScriptCore on performance. It lets us embed the ClojureScript app into our Clojure app so it can perform the rendering in-process in the JVM
> GraalVM's polyglot abilities to load the JavaScript artifact from the ClojureScript app into the Clojure JVM and directly call the function with almost no overhead
I think Clojure is uniquely positioned here in its ability to fuse these JS<->JVM technologies using a single language and, in this instance, fully supplant the need for nodejs. Very impressive!
That is very true. Even spending years writing nodejs projects I have never felt what truly "code-reuse" is about. Even with the same language being on both sides there's a huge difference between front-end and back-end. I was surprised to find out - Clojure lets you do that so elegantly, even though you essentially on two, completely different platforms much of the code can be re-used.
The sibling response from fulafel is definitely the central argument. I would also add that Clojure has excellent production-quality "interop" with all of its host languages, such that end-to-end ergonomics are relatively painless e.g. CLJS<->JS<->Graal Polyglot<->Java<->Clojure
There was briefly (now deleted) a response to fulafel's comment which essentially pointed out how JavaScript itself should be considered a production-quality language that is up to the task. After all, JavaScript can also now be used to build JVM applications thanks to GraalJS ...except I wouldn't bet on that technology direction gaining much traction at this point in time (unless maybe Oracle has a trick up its sleeve).
Clojure has "reader conditionals" which enable you to write a single file and only have divergent code paths when you need to do something that is JVM or JS specific (or CLR-specific, if you're into that).
It's super helpful for shared libraries. A lot of our code can be shared between JVM servers, JS lambdas, or JS frontend code without much development effort. It's mostly just a matter of naming a file .cljc and you're off to the races.
Great to see this, as I'm leaning the Fulcro/Pathom.
The idea of server-side rendering is fascinating. With correct abstraction, there's no extra code required for every component at all. And there's no more ad-hoc client-side script in order to rescue back-end HTML anymore.
It's just annoying currently it's only easier on Node.js until WASM decades arrives.
The prospect of doing React server rendering within the JVM, rather than in node, used to be a lot more attractive to me before I switched to containerizing my apps, specifically with kubernetes.
Now, the benefit of using the best tool for the job, and separating concerns (the API and the React server renderer can be deployed, logged & scaled independently) far outweighs the overhead of managing and connecting several different runtimes, because that's trivial with k8s.
The only slight advantage I can think of is loading data on server renders 'in-process' and not having to go via http, though I emphasise slight as this is certainly not a bottleneck and not something I worry about at all frankly.
I think this is cool, and I get that Clojure + Clojurescript add another reason to pair these things together and perhaps this is quite a Clojure-specific thing, but just wondering if anyone would pick this over running separate JVM + node services in k8s or similar (assuming that's an option)?
At Nextjournal, it won't stop with server side rendering. For example we're using ProseMirror as the rich text editor in the browser. For real-time collaboration on notebooks, we want to use ProseMirrors out of the box support for it: http://prosemirror.net/docs/guide/#collab
This means our server has to provide the "central authority". This leaves us again with the choice of:
1) expose this central authority in a nodejs service via http to our Clojure/JVM app (which manages also the websocket connections and database persistence)
2) rewrite the central authority and applying the transformation functions in Clojure/Java and maintain compatibility with the Javascript implementation
3) leverage the polyglot abilities from GraalVM to just call ProseMirror's transformation functions from our Clojure code
Here, 3) seems to be the obvious choice, as throughput is much higher than for occasional server side rendering and the http overhead for the nodejs-service approach would be a deal breaker.
Ah, ok, really interesting thanks. With this type of deep integration & communication needed between the two, I can see why running everything in the same JVM is a better solution.
I've noticed HackerNews has a lot of Clojure activists posting.
I worked with Clojure for about a month. Then I decided to go back to NodeJS.
- I have no need to java or JVM.
- The Clojure stack traces aren't easily decipherable
- One doesn't need Clojure for functional, immutable programming. NodeJS is flexible & has a massive community with tons of packages, including ones for immutable work. Functional programming on the other hand is simple-- just create & use JS functions (in the context of JS that is).
- Ultimately I saw no need for Clojure
What I do see though, is a small group of outspoken activists pushing clojure.
Now, why don't I want to use it, besides what I've written above?
Clojure is owned by Cognitect. Any changes to be made must be (very slowly or not at all) approved by Rich Hickey. This is a language with a development/expansion/growth bottleneck of one person.
This particular person considers the language his property-- which it is, he created it after all.
But once I realized this, I immediately moved back to the NodeJS & Python communities.
Also, Clojure libraries are mostly abandoned. Clojure's heyday seemed to be around 2005-2013 or so. Sure, you can find a couple recent ones like Reagent (for ReactJS rendering) which is a few versions behind ReactJS.
After working with it though, I saw no real benefit over simply using ReactJS directly. In fact, I found it cumbersome to have to work through two potential layers of errors: ClojureScript & Javascript.
Now we just see activists trying to pump it up in the news. I'd rather read about the interesting new things happening with JS and Python.
TL;DR; After working at a company with Clojure & ClojureScript, I realized that:
1. It's practically closed source
2. Most of its packages are abandoned
3. There is a small vocal group of folks pushing it... despite the fact that the community leaders seem to have (and claim to have) no interest in the community that has grown around the language.
4. Personally, I'd rather work with React directly than some transpiled language on top of it (which I have no use/need for, given that I have no use/need for java)
What I like about Clojure is that it allows me to build things on top of both the Java as well as the JavaScript ecosystem while using a very well designed simple language that comes with a friendly very supportive community.
This means I benefit from a lot of the things that are going on in JavaScript and Java land over time like improvements in runtimes and libraries. Being able to use React from ClojureScript or being able to use GraalVM is actually a good example for this.
I do think that onboarding and figuring out what went wrong and why when you run into errors could be smoother. That said a lot of community effort is going into this recently.
In hindsight I wish I had looked into Clojure earlier.
No need to be bitter just because you have failed to grasp what the language offers. There are good reasons why people keep discovering it and keep talking about it.
Clojure is not "owned" by Cognitect, it's an open-source language. In a sense it's as much "owned" as Rust is owned by Mozilla, C# by MSFT and Golang by Google. Yes, changes to the core ultimately do need to be approved by Rich Hickey and that's not necessarily a bad thing. Clojure's stability is something of a legend. In no other language ecosystem you can update things with such impunity. Where other languages start crumbling under their own weight, Clojure over the years stayed true to its core principles - it's predictable, moving from one major version to another won't cost you weeks of your time. I don't know where you get the notion of Clojure libraries being abandoned. Just because people not coming up with yet another front-end framework every couple of weeks?
I bet you just don't know Javascript to the point (or haven't worked on large enough projects) when it starts feeling very tiresome. Clojurescript offers multitude of tools to make it easier. That's why dev surveys like StackOverflow and State of JS show that Clojure is mainly chosen by more experienced programmers.
Frankly, even one full month of working with any language is not enough to learn its idioms and become comfortable with it. You didn't like - it's fine, you have your own reasons. There are people who do like it and you're struggling to understand why. No, they are not fanatics, they are pragmatists. For example: whenever I need to write code in any language and for whatever reason it cannot be Clojure - I would first do my prototyping in Clojure and then translate it to the other language. Even doing that I'm still much more faster.
Maybe you’ve never heard about Clojure, but it’s had a huge impact on you how program front-ends regardless.
Redux, immutable data, time travel debugging, hot reloading — all of this has been inspired by the Clojure community.
"Practically closed source" is a funny way to say "open source".
I have not run across any Clojure libraries I wanted to use that were "abandoned". I've found some that have a low version number (< 1.0) and haven't had any commits in the past couple years, but that's because they do everything they set out to do, and have no (reported) bugs. I wish other ecosystems were this stable.
I'm not sure exactly what complaint 3 is about. Is it that the leaders of a project aren't doing a good job of marketing and positioning, and don't understand their users? The first release of Linux was "just a hobby, won't be big and professional", and warning it "is NOT portable" and "probably never will support anything other than AT-harddisks". Python was developed for the Tanenbaum's Amoeba OS. If we use that as our barometer of a valid open source project, I don't think any project in the world is going to be judged suitable.
The word "transpiled" seems to only exist so people can make fun of other programming languages. (Similarly, calling its users "outspoken activists".) Your JavaScript has a virtual machine, too. Are you suggesting it's better because it lacks an explicitly specified bytecode?
https://github.com/graalvm/graal-js-jdk11-maven-demo
reply