Hacker News Reader

Comment by Scarbutt | Hacker News Reader

Why use the language with the most horrible startup time for a GUI framework though? The core might be C/C++, but users will write their app in Clojure. GraalVM also still has big limitations.

View on HN

The article explained most of it.

1) Author wants to use Clojure and is funded by a Clojure organization.

2) Author wants write-once/run-anywhere, which the JVM provides.

3) Author wants live interactive development which Clojure can provide.

4) Author wants multi-core support, and fast runtime, which JVM provides.

5) Author wants a declarative data oriented approach, which Clojure is good at.

Finally, the author acknowledges they are concerned about startup time, but believe their is hope either with GraalVM native compilation support, or a custom Clojure runtime.

As far as I understand, the core graphics library will be Skia, and it’s C++. So to some extent, your wish has been granted.

What wish?

I am sorry, I mistakenly assumed that you thought it would be better if the new GUI library used some language like C++ instead of Clojure.

There would still be JVM startup time even if some parts of the process delegate to native code. Though the OP acknowledges this and still thinks this is the best approach (and plans on mitigating the issue as much as possible). I'm of a similar mind: desktop apps tend to be long-lived and a few tens or even hundreds of milliseconds at startup shouldn't really matter.

JVM startup time is not great but it's not horrible either. Especially in the context of desktop apps that are often started once and kept running for a long time. With some care it is definitely possible to spin up a JVM and display an initialized window within 1 or 2 seconds. Which is roughly the same time as Gimp or Krita or Thunderbird take to startup on my machines.

I even have a few git-style CLI tools that bootstrap a JVM on each invocation without using optimized graalvm/native images.

JWM (a window library that I plan to use) shows a fully initialized window in 600-700 ms on M1 mac for me. That’s without Clojure, but with JVM overhead

https://github.com/humbleui/jwm

If your estimation of "time to window" is correct, clojure seems like a very bad choice for this undertaking.

I guess you are not familiar with Clojure, it adds a lot overhead over the overhead of the JVM to startup time.

Just to add some reference to why it can take a long time to start a REPL (for example):

> As it turns out, Clojure start time is a complicated and multi-dimensional topic. Clojure projects are slow to start not only because of JVM — JVM itself starts in ~50 ms — but because of JVM specifics the classes are loaded slowly. Clojure projects are slow to start not only because of Clojure — Clojure itself starts in ~1 second — but because of Clojure specifics, the namespaces, especially not AOT-compiled one, are loaded slowly. And so on.

http://clojure-goes-fast.com/blog/clojures-slow-start/

A more recent comparison of Clojure, Java and some other Clojure-inspired languages:

https://stuartsierra.com/2019/12/21/clojure-start-time-in-20...

Reply on news.ycombinator.com