3 ms·

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 t

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.

recursivedoubts 5y ago
i can't speak for nim, but htmx is a dependency-free, 10k javascript library that doesn't require a build step
- tata71 5y ago
  Why aren't more people using this?
ajusa 5y ago
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 5y ago
  would be interesting to know the total size of the program including deps sounds extremely tight given the functionality
  - ajusa 5y ago
    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/ https://hookrace.net/blog/nim-binary-size/
    - oneplane 5y ago
      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.

recursivedoubts 5y ago

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

tata71 5y ago
Why aren't more people using this?

ajusa 5y ago

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 5y ago
would be interesting to know the total size of the program including deps sounds extremely tight given the functionality
- ajusa 5y ago
  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/ https://hookrace.net/blog/nim-binary-size/
  - oneplane 5y ago
    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.