pomsky VS regex-automata

I started with JS, and my first step was to write a simple script that checks if a regex is valid. I can call this script from Rust, but there's a problem: Starting a nodejs process takes about 100ms, which is not acceptable, especially for fuzzing.

I noticed this when a test case of a parser I wrote failed in CI on Windows. I then learned that the default stack size on Windows is only 1 MiB whereas its 8 MiB on Linux if I remember correctly. The parser has a hard-coded recursion limit to prevent stack overflows, which is currently set to 128. However, this limit is lower than necessary on Linux, and might still be too high for some platforms (embedded?)

I was informed that Rulex is a registered trademark and I'm not allowed to use the name for my project. A lawyer contacted me and gave me a week to rename the project, so I have to come up with a different name :(

In the other discussion, there's also a link to Rulex, which has similar goals but is more concise. Also claims to compile to multiple regex dialects.

Something similar happened to me a week ago. Someone emailed me that they found panics in rulex, and then created a PR to fix them. They even explained to me how to create a security advisory on GitHub because the panics could be used to DoS someone. It was very helpful.

Sorry for not being more specific. Since this is a parser, the span points into the text file that is being parsed, so it's not that relevant for most libraries. Here is the parser, it uses nom parser combinators. Unfortunately, and adding the spans to the errors involves some boilerplate.

I welcome contributions for rulex. It's a medium-sized project that should be fairly easy to understand, and has some "good first issues" :)

Rulex – A new, portable, regular expression language\ (102 comments)

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.