4 ms·

Website is served from nine Neovim buffers on my old ThinkPad

139 points by todsacerdoti 1y ago

miyuru 1y ago
For me it resolves to 198.74.55.216 which is a Linode USA IP. No IPv6. No mention of why it needs to go through a Linode server.
- messe 1y ago
  They might not have a static public IP, perhaps they're even behind CGNAT.
- conradev 1y ago
  I have my public gateway on a Hetzner server routing traffic to an overlay network of my rinky-dink servers. Hetzner’s static IP is cheaper and more stable than one I could get from an ISP.
- wink 1y ago
  Also if for some reason you get DDoSed you can probably switch that VPS a lot quicker than getting a new static IP at home, if at all.
  - miyuru 1y ago
    Sad state of the legacy internet. This is a solved problem with IPv6. no wonder the why the corporations profiting from it delaying the migration.
yupyupyups 1y ago
Horrific
- yupyupyups 1y ago
  Jokes aside, it's still cool you managed to do that.
  - barbazoo 1y ago
    I don’t get the joke here
    - cookiengineer 1y ago
      ^ probably an emacs user
- BirAdam 1y ago
  It may be horrific, but it's wonderful too.
NoahZuniga 1y ago
I'm no expert, but could it be that one contributing factor to the speed is that neovim stores the files in ram while Nginx has to go to disk for every request?
- diffuse_l 1y ago
  I'm pretty sure that the website will reside in cache in any case.
  - cr125rider 1y ago
    Yup! The kernel will pull the page from disk and keep it in its disk cache in RAM. Since the kernel is solely in control of what gets written to disk it can be sure it doesn’t become stale, just “dirty” when it gets updated. It will then flush it to disk, but still keep active, hot pages in memory.
    - gnyeki 1y ago
      Yes, neither Nginx nor Neovim should be hitting the disk when serving the requests. One difference I can imagine is context switching due to system calls. If Nginx incurs a context switch when it calls into the kernel for the disk cache, then it suffers a performance penalty. Neovim avoids this because the file contents are loaded into a table. When requests are served, getting the content is done fully in userspace. I have no idea if this actually accounts for the performance difference though.
- jerf 1y ago
  Computers are fast. HTTP requests are not that hard. You have to go down to position 480-ish on the latest TechEmpower Fortune benchmark [1] to find a framework that is serving ~10,000 requests per second on this simple benchmark, and as that is running on a higher-spec system and possibly with more threads than "this guy's random laptop he had lying around" (although by the time you get that low in the benchmarks I suspect we're into single-thread-only frameworks) you could probably go to all but the last three to get something comparable in performance. (Yes, this is not a comparable task, because I'm making a point about speed of HTTP in general not static file serving.) Also as mentioned nginx on a blog site will certainly not be hitting the disk. Broadly speaking in 2025 if a website is slow it is 100% the fault of the app-specific code being run in the web request. I've been HN'd before on a very small VPS but since my blog is now all static content it doesn't even notice... even when it was making 4 or 5 DB reads per page it didn't notice. This web server is basically fast not because "it's fast" but simply because there's no reason for it to be slow. That's how computers are nowadays; you really have to give them a reason to be slow for a task like this. You'd think everyone would know this but I fight a surprising amount of rule-of-thumb estimates from coworkers based on 2000 or 2010 performance of systems, even from developers who weren't developing then! It's really easy to not realize how much performance you're throwing away using a scripting language, and using multiple fancy runtime features that have multiplicative costs at runtime, and make bad use of databases with too many queries, that fail to do even basic optimizations on said databases, and come away thinking that 50 queries per second is a lot, when in fact in 2025 you hardly even need to consider the performance of the web requests themselves until you're into the range of interest until you're in the many thousands per core... and that's just when you need to start thinking about it. Depending on what you are doing, of course, you may need to be considering how your code runs well before that, if your web requests are intrinsically expensive. But you don't need to worry about the web itself until at least that level of performance, and generally it'll be your code struggling to keep up, not the core web server or framework. [1]: https://www.techempower.com/benchmarks/#section=data-r23 https://www.techempower.com/benchmarks/#section=data-r23
giancarlostoro 1y ago
I like that the author put it on a subdomain, probably a smarter move. I have an old laptop I keep installing Linux on and not deciding what I want to do with it. Maybe I should build quirky web servers on it..
- para_parolu 1y ago
  I recently had a lot of fun while playing with nixos using claude code.
jrop 1y ago
This is what I love HN for. "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should". This awakens things I've been thinking about Neovim for a while now: now that libuv is embedded, there's really no reason not to use it as a cross-platform application runtime (except for the fact that that's horrific).
- deleted 1y ago
  [deleted]
ordinaryradical 1y ago
This has to be one of my favorite hacking articles I’ve read on HN. The analysis, concept, and execution :chefskiss:
jacquesm 1y ago
That's a fun article. As for the 'is this even safe' angle: this article should be the go-to example for anybody that thinks that their code will never be run in the context of unchecked requests coming in over the network because that would make no sense at all.
mvieira38 1y ago
This is the kind of stuff that made me like HN initially. Great job
-peregrine- 1y ago
[dead]
tim333 1y ago
>There is that famous story ... German air traffic control system in a headless instance of Emacs. I hadn't come across that. It was an entertaining read https://www.reddit.com/r/emacs/comments/lly7po/do_you_use_emacs_lisp_as_a_general_purpose/gnvzisy/ https://www.reddit.com/r/emacs/comments/lly7po/do_you_use_em...

139 points by todsacerdoti 1y ago

For me it resolves to 198.74.55.216 which is a Linode USA IP. No IPv6. No mention of why it needs to go through a Linode server.

messe 1y ago
They might not have a static public IP, perhaps they're even behind CGNAT.
conradev 1y ago
I have my public gateway on a Hetzner server routing traffic to an overlay network of my rinky-dink servers. Hetzner’s static IP is cheaper and more stable than one I could get from an ISP.
wink 1y ago
Also if for some reason you get DDoSed you can probably switch that VPS a lot quicker than getting a new static IP at home, if at all.
- miyuru 1y ago
  Sad state of the legacy internet. This is a solved problem with IPv6. no wonder the why the corporations profiting from it delaying the migration.

yupyupyups 1y ago

Horrific

yupyupyups 1y ago
Jokes aside, it's still cool you managed to do that.
- barbazoo 1y ago
  I don’t get the joke here
  - cookiengineer 1y ago
    ^ probably an emacs user
BirAdam 1y ago
It may be horrific, but it's wonderful too.

NoahZuniga 1y ago

I'm no expert, but could it be that one contributing factor to the speed is that neovim stores the files in ram while Nginx has to go to disk for every request?

diffuse_l 1y ago
I'm pretty sure that the website will reside in cache in any case.
- cr125rider 1y ago
  Yup! The kernel will pull the page from disk and keep it in its disk cache in RAM. Since the kernel is solely in control of what gets written to disk it can be sure it doesn’t become stale, just “dirty” when it gets updated. It will then flush it to disk, but still keep active, hot pages in memory.
  - gnyeki 1y ago
    Yes, neither Nginx nor Neovim should be hitting the disk when serving the requests. One difference I can imagine is context switching due to system calls. If Nginx incurs a context switch when it calls into the kernel for the disk cache, then it suffers a performance penalty. Neovim avoids this because the file contents are loaded into a table. When requests are served, getting the content is done fully in userspace. I have no idea if this actually accounts for the performance difference though.
jerf 1y ago
Computers are fast. HTTP requests are not that hard. You have to go down to position 480-ish on the latest TechEmpower Fortune benchmark [1] to find a framework that is serving ~10,000 requests per second on this simple benchmark, and as that is running on a higher-spec system and possibly with more threads than "this guy's random laptop he had lying around" (although by the time you get that low in the benchmarks I suspect we're into single-thread-only frameworks) you could probably go to all but the last three to get something comparable in performance. (Yes, this is not a comparable task, because I'm making a point about speed of HTTP in general not static file serving.) Also as mentioned nginx on a blog site will certainly not be hitting the disk. Broadly speaking in 2025 if a website is slow it is 100% the fault of the app-specific code being run in the web request. I've been HN'd before on a very small VPS but since my blog is now all static content it doesn't even notice... even when it was making 4 or 5 DB reads per page it didn't notice. This web server is basically fast not because "it's fast" but simply because there's no reason for it to be slow. That's how computers are nowadays; you really have to give them a reason to be slow for a task like this. You'd think everyone would know this but I fight a surprising amount of rule-of-thumb estimates from coworkers based on 2000 or 2010 performance of systems, even from developers who weren't developing then! It's really easy to not realize how much performance you're throwing away using a scripting language, and using multiple fancy runtime features that have multiplicative costs at runtime, and make bad use of databases with too many queries, that fail to do even basic optimizations on said databases, and come away thinking that 50 queries per second is a lot, when in fact in 2025 you hardly even need to consider the performance of the web requests themselves until you're into the range of interest until you're in the many thousands per core... and that's just when you need to start thinking about it. Depending on what you are doing, of course, you may need to be considering how your code runs well before that, if your web requests are intrinsically expensive. But you don't need to worry about the web itself until at least that level of performance, and generally it'll be your code struggling to keep up, not the core web server or framework. [1]: https://www.techempower.com/benchmarks/#section=data-r23 https://www.techempower.com/benchmarks/#section=data-r23

giancarlostoro 1y ago

I like that the author put it on a subdomain, probably a smarter move. I have an old laptop I keep installing Linux on and not deciding what I want to do with it. Maybe I should build quirky web servers on it..

para_parolu 1y ago
I recently had a lot of fun while playing with nixos using claude code.

jrop 1y ago

This is what I love HN for. "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should". This awakens things I've been thinking about Neovim for a while now: now that libuv is embedded, there's really no reason not to use it as a cross-platform application runtime (except for the fact that that's horrific).

deleted 1y ago
[deleted]

ordinaryradical 1y ago

This has to be one of my favorite hacking articles I’ve read on HN. The analysis, concept, and execution :chefskiss:

jacquesm 1y ago

That's a fun article. As for the 'is this even safe' angle: this article should be the go-to example for anybody that thinks that their code will never be run in the context of unchecked requests coming in over the network because that would make no sense at all.

mvieira38 1y ago

This is the kind of stuff that made me like HN initially. Great job

-peregrine- 1y ago

[dead]

tim333 1y ago

>There is that famous story ... German air traffic control system in a headless instance of Emacs. I hadn't come across that. It was an entertaining read https://www.reddit.com/r/emacs/comments/lly7po/do_you_use_emacs_lisp_as_a_general_purpose/gnvzisy/ https://www.reddit.com/r/emacs/comments/lly7po/do_you_use_em...