OP here, I guess things have changed? AFAIK there was no pricing when I set it up... I just put the image with the link, certainly wouldn't pay for it :D
EDIT: So the payment is to have a little space on their own website, which they call a "project page" e.g. https://notbyai.fyi/hi/not-by-ai/
They suggest "linking to it for verification", but it really seems both unnecessary and optional
I think the concept of slow is relative here, for a no configuration start (from a fresh install) alacritty is slower by a factor of 4 https://news.ycombinator.com/item?id=40559084
However the absolute times are still probably not noticable unless you often cold-start terminals.
That's a valid point. It might be more about using the right tool for the task. For example, using tmux for persistent terminal windows can help. A setup where the main compilation terminal (subFloat) and smaller terminal instances for chat/irssi/nmpc (mS) run within a tmux session ensures persistence even if foot crashes (or is killed for applying configuration updates) as noted in the post ^_^
btop might be measuring the wrong thing here, but alacritty on my box shows 93M using the same interface. I remember benchmarking foot and alacritty (also kitty) pretty extensively a few years ago, and settled on foot.
Though of course, the memory usage on modern machines is really not a major issue, but the configuration update, along with the tmux session death was annoying..
EDIT: Some timing metrics..
foot -s &
hyperfine --warmup 8 'alacritty -e true' 'foot -e true' 'footclient -e true'
Benchmark 1: alacritty -e true
Time (mean ± σ): 99.0 ms ± 14.2 ms [User: 58.5 ms, System: 33.4 ms]
Range (min … max): 82.7 ms … 148.3 ms 32 runs
Benchmark 2: foot -e true
Time (mean ± σ): 37.2 ms ± 2.3 ms [User: 40.3 ms, System: 9.5 ms]
Range (min … max): 33.8 ms … 43.7 ms 83 runs
Benchmark 3: footclient -e true
Time (mean ± σ): 22.8 ms ± 4.3 ms [User: 0.9 ms, System: 0.8 ms]
Range (min … max): 18.2 ms … 63.6 ms 133 runs
Summary
footclient -e true ran
1.63 ± 0.32 times faster than foot -e true
4.35 ± 1.03 times faster than alacritty -e true
timing footclient -e true is not actually measuring what you think its measuring. It's measuring the time it takes to open a socket and write a few bytes to it. Not the time it takes to run true in a new window and then close it. And just FYI both alacritty and kitty have server/client modes too. foot without server client mode does indeed startup faster than any GPU based terminal emulator because GPU based terminal emulators have to probe the GPU card(s) ont he system for their capabilities which is approx 100ms of unavoidable delay until someone convinces the kernel developers to cache this data.
In client server mode all of foot/alacritty/kitty/urxvt will open windows in a few ms.
It is the framework used by meson which was how I came across it. It's different, for short API documentation the yaml structure probably works better.
> I have to say though, most compilers courses I've seen have an inordinate emphasis on parsing and little else.
Which is sad, because parsing is simpler than the theory-heavy books make it out to be and understanding optimization is probably more practically important for programmers.
I mostly agree. Parsing is as complex as the theory-heavy books make it out to be (and more as you keep going down the rabbit hole). But the necessity of that complexity is isolated to some pretty niche areas. If you've been brushing up against the limitations of straight forward parsing for a number of years and are still finding them wanting, then you might be one of the few people who need to delve deeper.
Almost everyone should just hand code a recursive descent parser and then move on with their lives. I've been a part of a few book clubs at work that tried to dig into compiler books and the same thing kept happening. People get bogged down by the parser theory and give up. One of the people even eventually left to work on cryptograph for a company doing government contracts. These people could understand complex topics, but apparently parsing theory is a bridge to far for nearly everyone.
the happy path may very well be "simpler," but I get the impression a lot of the newer parsing techniques focus on error recovery which is what made clang and friends game-changers because they emit helpful and often actionable error messages on malformed input
it's a whole other ballgame when writing interactive parsers (as one would for IJ or I think tree-sitter, too) where the document spends the majority of its life in an erroneous state
now, I can appreciate diving into such an 80/20 topic may be too much for a compiler course, but as for really rolling out a compiler or editor plugin, it's the difference between "this is crap" and "wow, that's genuinely helpful"
EDIT: So the payment is to have a little space on their own website, which they call a "project page" e.g. https://notbyai.fyi/hi/not-by-ai/
They suggest "linking to it for verification", but it really seems both unnecessary and optional