Hacker News Reader

Comment by m45t3r | Hacker News Reader

I concur. I am writing a new project in Python after some months writing exclusively Clojure. I decided to write the code using small, pure functions and avoiding classes unless strictly necessary makes the codebase much easier to maintain in the long run.

However I don't think the Python ecosystem is immature, for me it is the contrary. This project started with Python since I didn't find a good way to reduce the Clojure startup time, and believe me I tried everything I found (from GraalVM to ClojureScript). And there is gaps everywhere in Clojure ecosystem when you want to create command line tools, while Python has literally everything I needed.

View on HN

BTW, if there is anyway that I can get Clojure startup time below 0.1s (actually, until 0.2s wouldn't be so bad, but this is my limit) that doesn't involve something like a daemon running I would be all ears. I would really like "real" Clojure in this case (i.e.: not ClojureScript), since the ecosystem from Clojure is much better.

Other options like SBCL would allow this easily:

  $ echo "(format t \"Hello\!~%\")" | cat - > /tmp/test.lisp
  $ time sbcl --script /tmp/test.lisp
  Hello!

  real 0m0.014s

Executables are easily created, though they are not small in SBCL.

  $ sbcl
  This is SBCL 1.5.9, 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.
  * (sb-ext:save-lisp-and-die "howfast"
       :toplevel (lambda () (format t "Hello!~%"))
       :executable t)
  [undoing binding stack and other enclosing state... done]
  [performing final GC... done]
  [defragmenting immobile space... (fin,inst,fdefn,code,sym)=1026+935+18027+18435+25326... done]
  [saving current Lisp image into howfast:
  writing 0 bytes from the read-only space at 0x20000000
  writing 432 bytes from the static space at 0x20100000
  writing 26804224 bytes from the dynamic space at 0x1000000000
  writing 1990656 bytes from the immobile space at 0x20300000
  writing 11935744 bytes from the immobile space at 0x21b00000
  done]
  
  $ time ./howfast
  Hello!

  real 0m0.016s

Did Graal not work because of the limitations in the AOT compiler? I haven't spent a lot of time with it but the few experiments for e.g. little command line utils yield startup indistinguishable from C or Go apps. (Compilation time required by graal still completely non-competitive but could potential work as a packaging step...)

Yeah. When you start anything remotely complex with GraalVM it starts to break, i.e.: anything related to eval (and this wasn't my code actually, however a good part of Clojure ecosystem depends on eval).

https://planck-repl.org/

Might help? Clojurescript, but fast start up at least...

Planck/Lumo for actual projects are really slow and I don't know why (0.5s of startup time). For some reason, the REPL is fast, and I didn't investigate why REPL is fast and an actual project is slow.

Probably not using clojure and using another lisp with a good startup time.

Using a Common Lisp or Scheme with AOT compiler like SBCL or Chez would have sorted it out.

Reply on news.ycombinator.com