Hacker News Reader

Comment by oneplane | Hacker News Reader

At this point I'm more worried about the whole supply chain of libraries and dependencies in the background than how nice the abstractions are.

It used to be that a powerful demo of a framework or language would be a pretty sweet starting point, but I'm not so sure about that anymore.

View on HN

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.

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

sounds extremely tight given the functionality

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/

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.

i can't speak for nim, but htmx is a dependency-free, 10k javascript library that doesn't require a build step

Why aren't more people using this?

Reply on news.ycombinator.com