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.
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).
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-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).