4 ms·

Thank you! I read some time ago that compilation to binaries is not really a solved problem. Also the ecosystem was very lean. At the same time you need to incl

Thank you! I read some time ago that compilation to binaries is not really a solved problem. Also the ecosystem was very lean. At the same time you need to include a dependency for everything because the standard library is also lean. You’re mostly right about Elixir but Phoenix is not opinionated, at all. It’s code-generation oriented only if you want to use the generators. I don’t use them.

vindarel 2y ago
ack, thanks. I still want to see what I'm missing, so I'll keep trying. Compilation to binaries works fine. A SBCL binary will weight ±35MB (compressed, 120MB uncompressed). This includes everything (compiler, debugger etc). A bigger app with dozens of deps doesn't grow too fast, like ±40MB for a web app. I think that's in the ballparks of a growing Go app. LispWorks allows to shrink the binary size to ±4MB (but then you can't connect to it remotely and live reload the running image). Start-up times are very fast. A SBCL binary relies on GLIBC. There was a patch for truly static binaries, needs more care (https://www.timmons.dev/posts/static-executables-with-sbcl-v2.html https://www.timmons.dev/posts/static-executables-with-sbcl-v...) It's true you need to choose and include a dependency for common tasks: HTTP client, JSON and CSV… As for "lean", well, it depends. See awesome-cl. CL's ecosystem is richer for some tasks than other emerging and trendy languages, poorer in some areas. Interfacing with Java or Python is possible (ABCL and LispWorks, py4cl2).
citizen_friend 2y ago
ANSI Common Lisp was criticized when it came out for having a bloated standard library and feature set. It’s not extensive like python, but it’s not C.
- p_l 2y ago
  In fact, some of the presently annoying warts can be derived from late decisions on the theme of "we already have a bloated standard, let's not add more". Over time a lot of them became de facto extensions (MOP, gray streams), or there are de facto extensions that fill the same niches in different way (ASDF)

vindarel 2y ago

ack, thanks. I still want to see what I'm missing, so I'll keep trying. Compilation to binaries works fine. A SBCL binary will weight ±35MB (compressed, 120MB uncompressed). This includes everything (compiler, debugger etc). A bigger app with dozens of deps doesn't grow too fast, like ±40MB for a web app. I think that's in the ballparks of a growing Go app. LispWorks allows to shrink the binary size to ±4MB (but then you can't connect to it remotely and live reload the running image). Start-up times are very fast. A SBCL binary relies on GLIBC. There was a patch for truly static binaries, needs more care (https://www.timmons.dev/posts/static-executables-with-sbcl-v2.html https://www.timmons.dev/posts/static-executables-with-sbcl-v...) It's true you need to choose and include a dependency for common tasks: HTTP client, JSON and CSV… As for "lean", well, it depends. See awesome-cl. CL's ecosystem is richer for some tasks than other emerging and trendy languages, poorer in some areas. Interfacing with Java or Python is possible (ABCL and LispWorks, py4cl2).

citizen_friend 2y ago

ANSI Common Lisp was criticized when it came out for having a bloated standard library and feature set. It’s not extensive like python, but it’s not C.

p_l 2y ago
In fact, some of the presently annoying warts can be derived from late decisions on the theme of "we already have a bloated standard, let's not add more". Over time a lot of them became de facto extensions (MOP, gray streams), or there are de facto extensions that fill the same niches in different way (ASDF)