3 ms·

After hearing about GraalVM first time at a PolyConf talk last year I sat down with one of the GraalVM folks and we (well, I was just providing info) did a few

by wink 8y ago

After hearing about GraalVM first time at a PolyConf talk last year I sat down with one of the GraalVM folks and we (well, I was just providing info) did a few performance measurements if this could speed up the startup time (especially for leiningen tasks) - the preliminary results were pretty cool. So if you're using Clojure and Leiningen and are annoyed by the long startup times... there's potential :)

Rovanion 8y ago
Did Leiningen compile through Graal without modification?
- wink 8y ago
  No, at least not back then. Otherwise we might have an official branch or PR already. I didn't really follow up on this, this was just a quick hack session to see if we could get something like "lein version" or "lein deps" or something to run and compare the speed. One main problem I also see is the distribution. Currently leiningen only needs "some sort of java executable" and then the rest is pulled in. So would you have to have GraalVM installed or could this also be bootstrapped.
zcam 8y ago
It's not all unicorns though. Performance can vary quite a lot from task to task, also compile times suffer a lot and you lose some dynamic features. So from what I understand it might be useful for clojure cli apps, but at this point I am not sure it brings a lot, but this is early days. The cool part is the polyglot capabilities imho. Then there's the elephant in the room: the licensing and potential changes in the long run. For clojure if you want decent cli/startup experience there's always cljs, lumo or you can go with something like fennel-lang, a clojure looking lisp that "transpiles" to lua(jit), so 0 overhead compared to lua and super fast startup. https://fennel-lang.org/ https://fennel-lang.org/
- wink 8y ago
  Yeah, but I don't see anyone rewriting leiningen in cljs anytime soon. For general CLI tools, yes, I'd also look into cljs at this time.
  - zcam 8y ago
    You'd be surprised, there are people in the community with some clever ideas to do that with a (fast)client/server model and change diffing (incremental builds), but it's super early days. With tools.deps and the need of some companies for more advanced build setup a lot of people are actually thinking about these issues.
    - wink 8y ago
      I'm not denying that someone, somewhere is working on something. But I'd be surprised indeed, I'm not watching the whole clojure space closely, I can only say that no one hit the #leiningen irc channel or posted something on the bugtracker/proposed a PR yet. And the client/server model.. sure, nailgun and grenchman were a bit clunky, but none of these efforts have gained widespread adoption, afaik. Most people don't just go out of their way to tweak their build tool.
      - zcam 8y ago
        > And the client/server model.. sure, nailgun and grenchman were a bit clunky, but none of these efforts have gained widespread adoption, afaik. Most people don't just go out of their way to tweak their build tool. I was not thinking about these two, nor was I thinking about a patch for boot/lein. That said the slow startup issue is only really valid for cli apps (and maybe CI), if your dev workflow relies on re-starting your repl all the time, it's a broken workflow.
        jjwiseman 8y ago
        There is a group of people that love to say this ("If you're not using a repl or restarting your repl all the time, you're doing it wrong"), but I've been using Lisp for more than 20 years and I don't agree. A repl is nice, and I use one often, but it does have tradeoffs. One is persistent state--It can be quite easy to get your repl into a state where your code works, but if you run the app from scratch it doesn't because definitions are out of sync (e.g. you renamed a function, but forgot to change the name at a call site, so you end up calling an old version of the function.) Developing in a repl is nice, but it's not the only allowed or legitimate or even good way to do development in Lisp or other dynamic, interactive languages. Clojure has an issue with slow startup (another tradeoff made for good reasons that don't fit everyone's situation)--denigrating other people's development approaches doesn't solve that, it comes off as defensive.
zebraman 8y ago
For command-line applications, it opens up an interesting space. There was a post on HN a while ago: https://www.astrecipes.net/blog/2018/07/20/cmd-line-apps-with-clojure-and-graalvm/ https://www.astrecipes.net/blog/2018/07/20/cmd-line-apps-wit... though the system requirements for compilation are at the moment very onerous.
- wink 8y ago
  Apparently I missed this one, thanks! > So you have no excuses not to build your CLI tools in Clojure now. Well I do disagree with this part, see other sibling comments (not by me). I'm not even sure GraalVM is really production-ready, notwithstanding the potential licensing and long-term issues. I do agree it's at least worth trying.
  - zebraman 8y ago
    We are starting to do that, and for very simple operations, it works (like scripts for maintenance that we deploy remotely, and run as cron jobs). So far no big surprises, but we were very careful. The big minefield is that you do not really know which libraries will go boom and where, as any place could make use of class loading.
  - repolfx 8y ago
    What licensing issues do you have in mind. Graal and SubstrateVM are all GPL-with-classpath-exception licensed, same as Java itself. It's an open source license.

by wink 8y ago

Rovanion 8y ago

Did Leiningen compile through Graal without modification?

wink 8y ago
No, at least not back then. Otherwise we might have an official branch or PR already. I didn't really follow up on this, this was just a quick hack session to see if we could get something like "lein version" or "lein deps" or something to run and compare the speed. One main problem I also see is the distribution. Currently leiningen only needs "some sort of java executable" and then the rest is pulled in. So would you have to have GraalVM installed or could this also be bootstrapped.

zcam 8y ago

It's not all unicorns though. Performance can vary quite a lot from task to task, also compile times suffer a lot and you lose some dynamic features. So from what I understand it might be useful for clojure cli apps, but at this point I am not sure it brings a lot, but this is early days. The cool part is the polyglot capabilities imho. Then there's the elephant in the room: the licensing and potential changes in the long run. For clojure if you want decent cli/startup experience there's always cljs, lumo or you can go with something like fennel-lang, a clojure looking lisp that "transpiles" to lua(jit), so 0 overhead compared to lua and super fast startup. https://fennel-lang.org/ https://fennel-lang.org/

wink 8y ago
Yeah, but I don't see anyone rewriting leiningen in cljs anytime soon. For general CLI tools, yes, I'd also look into cljs at this time.
- zcam 8y ago
  You'd be surprised, there are people in the community with some clever ideas to do that with a (fast)client/server model and change diffing (incremental builds), but it's super early days. With tools.deps and the need of some companies for more advanced build setup a lot of people are actually thinking about these issues.
  - wink 8y ago
    I'm not denying that someone, somewhere is working on something. But I'd be surprised indeed, I'm not watching the whole clojure space closely, I can only say that no one hit the #leiningen irc channel or posted something on the bugtracker/proposed a PR yet. And the client/server model.. sure, nailgun and grenchman were a bit clunky, but none of these efforts have gained widespread adoption, afaik. Most people don't just go out of their way to tweak their build tool.
    - zcam 8y ago
      > And the client/server model.. sure, nailgun and grenchman were a bit clunky, but none of these efforts have gained widespread adoption, afaik. Most people don't just go out of their way to tweak their build tool. I was not thinking about these two, nor was I thinking about a patch for boot/lein. That said the slow startup issue is only really valid for cli apps (and maybe CI), if your dev workflow relies on re-starting your repl all the time, it's a broken workflow.
      - jjwiseman 8y ago
        There is a group of people that love to say this ("If you're not using a repl or restarting your repl all the time, you're doing it wrong"), but I've been using Lisp for more than 20 years and I don't agree. A repl is nice, and I use one often, but it does have tradeoffs. One is persistent state--It can be quite easy to get your repl into a state where your code works, but if you run the app from scratch it doesn't because definitions are out of sync (e.g. you renamed a function, but forgot to change the name at a call site, so you end up calling an old version of the function.) Developing in a repl is nice, but it's not the only allowed or legitimate or even good way to do development in Lisp or other dynamic, interactive languages. Clojure has an issue with slow startup (another tradeoff made for good reasons that don't fit everyone's situation)--denigrating other people's development approaches doesn't solve that, it comes off as defensive.

zebraman 8y ago

For command-line applications, it opens up an interesting space. There was a post on HN a while ago: https://www.astrecipes.net/blog/2018/07/20/cmd-line-apps-with-clojure-and-graalvm/ https://www.astrecipes.net/blog/2018/07/20/cmd-line-apps-wit... though the system requirements for compilation are at the moment very onerous.

wink 8y ago
Apparently I missed this one, thanks! > So you have no excuses not to build your CLI tools in Clojure now. Well I do disagree with this part, see other sibling comments (not by me). I'm not even sure GraalVM is really production-ready, notwithstanding the potential licensing and long-term issues. I do agree it's at least worth trying.
- zebraman 8y ago
  We are starting to do that, and for very simple operations, it works (like scripts for maintenance that we deploy remotely, and run as cron jobs). So far no big surprises, but we were very careful. The big minefield is that you do not really know which libraries will go boom and where, as any place could make use of class loading.
- repolfx 8y ago
  What licensing issues do you have in mind. Graal and SubstrateVM are all GPL-with-classpath-exception licensed, same as Java itself. It's an open source license.