biscuit VS regex-automata

No, it isn't the third release of a POSIX like OS research written in Go,

https://github.com/mit-pdos/biscuit

But there are other brave people exists like biscuit or gopher-os who can do it :)))

That's something I found in doing a bit of a dive on why ripgrep is so fast at doing a very specific kind of string search workload (Gallant / burntsushi / author of ripgrep is an actual wizard and contributes to Rust's regex engines, for reference). I wrote tiny proof of concepts in a variety of languages, all in my same style -- and sometimes my Go variants were as fast as the equivalent Rust/C (even in release / -O3/2 (every once in a blue moon, O3 makes no diff or is a slight regression in some exec paths)). I eventually found something about benchmarks in a related area, leading to this: https://benhoyt.com/writings/count-words/#performance-results-and-learnings. Somebody on the Go sub even linked me to the Biscuit OS: https://pdos.csail.mit.edu/papers/biscuit.pdf, which, tidbit, has Jon Gjengset (Crust of Rust legend) in the contribs list (https://github.com/mit-pdos/biscuit).

https://github.com/mit-pdos/biscuit maybe this

Go has been used to implement OS kernel code, e.g. in the Biscuit OS from MIT: https://github.com/mit-pdos/biscuit

Of course, the garbage collector did not exactly make it easier - but it's an interesting piece of software.

https://github.com/mit-pdos/biscuit says 5% slowdown over C. Garbage collection is going to require some more RAM, generally <=2x though.

I believe you're the second person to tell me they were confused by this, so there are probably several others confused but didn't say anything. I've added a warning to the top of regex-automata's README.

For anyone following along at home, we're having a very helpful discussion about the implementation I posted in my sibling comment here: https://github.com/BurntSushi/regex-automata/issues/30

My current technique only gets applied to alternations of simple literals. But the idea is generalizeable and I speculate that it is actually impactful to generalize it.

(I could use '_ => {}' instead of 'None' to save a few more.)

I do find the 'if let' variant to be a bit easier to read. It's optimizing for a particular and somewhat common case, so it does of course overlap with 'match'. But I don't find this particular overlap to be too bad. It's usually pretty clear when to use one vs the other.

But like I said, I could live without 'if let'. It is not a major quality of life enhancement to me. Neither will its impending extensions. i.e., 'if let pattern = foo && some_booolean_condition {'.

[1]: https://github.com/BurntSushi/regex-automata/blob/fbae906823...

[2]: https://github.com/BurntSushi/regex-automata/blob/fbae906823...

(The work on regex-automata 0.2 has been underway for over a year now.](https://github.com/BurntSushi/regex-automata/tree/ag/work) There's a lot done, but still a lot more to go. Once that's done, regex proper should be pretty close to a thin layer that glues regex-syntax, regex-automata, memchr and aho-corasick together. I don't currently expect regex to grow any more dependencies than that. And as it is, aho-corasick and memchr are both optional dependencies. Right now, regex-syntax is the only required dependency, but regex-automata will be added to that list.