https://go-review.googlesource.com/c/go/+/576015 this change to optimise errors.Is in the err == nil case was merged recently. It’s not included in the latest Go release, hence the stats here, but should end up in a release pretty soon I’d imagine.
Fun weekend project but definitely not production-ready (no tests, no error handling, concurrent requests will cause a race condition, etc.). If readers are looking for something production-ready to use, consider https://github.com/go-redis/redis_rate (which implements GCRA/leaky bucket), or https://github.com/ulule/limiter (which uses a much simpler algorithm, but has good middleware).
It was checking if the C compiled to detect the landlock feature, and there was a single character in the middle of the code that made it always fail to compile and therefore silently leave the feature disabled.
> Maybe it would be easier to have some kind of framework for compiler plugins that do extra checks. [...] But I haven't seen any language community do something like that. What am I missing?
Go has adopted a similar approach to this - they've made it fairly easy to write separate plugins that check stuff like this. The plugins aren't executed as part of the compiler though, they're standalone tools. For example, see golangci-lint, which bundles together a load of plugins of this kind.
Some of these plugins are shipped within the go command directly, as part of the "go vet" subcommand. (including a printf format check, which is similar to what's described in this post, i.e. it checks that arguments are of the correct type).
> Now, listen. I wish I could continue here and end with “… and this is why ZSH does it that way!”
https://github.com/zsh-users/zsh/blob/47c7bc9b1493c7374f076b... has a comment about this behaviour, but no justification. I think it's just an optimization to save a little bit of time by not forking, and to avoid having the zsh process hanging around taking resources for no reason.
I wonder if restoring the process leader before doing the exec would work out okay, or if that's just going to end up being differently confusing.
I suspect, on the whole, this was a clever idea in theory with unfortunate consequences in practice (much like most of my clever ideas) and would be better just being reverted.
However, I'm not usually a zsh user myself so I'm loath to file a bug given there may be actual zsh users out there who like/rely on this behaviour.
> However, I'm not usually a zsh user myself so I'm loath to file a bug given there may be actual zsh users out there who like/rely on this behaviour.
That sounds like reason for a “won’t fix” response more than a reason not to file the bug in the first place. If nothing else it provides an opportunity to explain why it is the way it is.
Yes, I've tried that one as well, but text input is too difficult and slow, whereas multiple choice is too easy. A lot of the time, I would be able to click correct option elimination method.
