4 ms·
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 avoidi
by m45t3r 7y ago
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.
- m45t3r 7y agoBTW, 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.
- novok 7y agoProbably not using clojure and using another lisp with a good startup time.
- deckiedan 7y agohttps://planck-repl.org/ https://planck-repl.org/ Might help? Clojurescript, but fast start up at least...
- m45t3r 7y agoPlanck/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.
- lispm 7y agoOther 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
- jonahbenton 7y agoDid 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...)
- m45t3r 7y agoYeah. 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).
- pjmlp 7y agoUsing a Common Lisp or Scheme with AOT compiler like SBCL or Chez would have sorted it out.