[ajusa]

As far as Nim's dependencies go in this case, it's literally just Karax (no dependencies), Jester (depends on httpbeast which has no dependencies) and treeform's ws library (no dependencies). So the only thing in this chain that isn't transparently being used is httpbeast. Thankfully I've read through that code and contributed a bit to that project, so I can reasonably trust it.

Nim has a smaller community, so the supply chain tends not to be more than one or two levels deep in my experience. This is also because the standard library is fairly large.

[recursivedoubts]

would be interesting to know the total size of the program including deps

sounds extremely tight given the functionality

[ajusa]

If I understood your point correctly you are talking about the binary size? Me naively compiling with `nim c -d:release` and running `strip` on it gives the server binary to be around 700kb, and it's dynamically linked to glibc. There are tricks and stuff to make this smaller [1], but it's already small enough and easy enough to deploy.

Plus Nim is fast! I can load the index page of this application at 90k requests per second single-threaded on a laptop from a few years ago.

[1]: https://hookrace.net/blog/nim-binary-size/

[oneplane]

That is a pretty neat result, it looks like with that custom linking magic you can make binaries even smaller. Makes sense if you consider the vast majority of standard libraries isn't actually used regardless of how you link.