Hacker News Reader

Comment by mhluongo | Hacker News Reader

It solves fast startup relative to the JVM.

JVM start-up time is below 50 msec. Is that so slow? (Measure a simple hello world, and you will see.) Any slowness above that comes from your code, not the JVM.

Maybe more accurately JVM based Clojure, as opposed to node based ClojureScript (Lumo).

Excuse my brevity. Definitely meant "Clojure on the JVM" vs other hosts.

That's a bit of a straw man though - Go is significantly faster to start than either.

They also mention static binaries which Node does not solve.

It's not a strawman at all- many of us who run Clojure have had to switch to other langs for parts of our infrastructure that require faster start-up time. Think Lambda / "serverless" computing, etc

Agreed it doesn't help with static dependencies, which is why I didn't mention it ;)

It is a straw man - you're justifying your suggested solution by comparing it to something that is already considered bad in the area. That's exactly what a straw man is.

You're suggesting the answer to "we need better startup time" must be "we need the best startup time possible"? In that case, Go is also bad. Everything should be hand-rolled assembler.

Many of us who actually run Clojure in production have been bit by this, and Clojurescript has been fast enough to alleviate the issue. Not a straw man, a community meme.

With pkg [1][2] and nexe [3] you can package ClojureScript on Node.js applications as a static binary. Of course, Go would be better in terms of size/performance, so it's now a matter of making tradeoffs between relative size/performance and team productivity. But at least for teams using Clojure/ClojureScript, this gives you that an additional option, where none existed.

[1] https://github.com/zeit/pkg

[2] https://clojurescript.org/guides/native-executables

[3] https://github.com/nexe/nexe

Reply on news.ycombinator.com