It's important to note that these are still regular expressions. They still conform to the same mathematical definition as the regular expressions we all love o

It's important to note that these are still regular expressions. They still conform to the same mathematical definition as the regular expressions we all love or hate, and in fact, the library uses regular expressions under the hood. It's basically just using new language constructs for the exact same capabilities. Now, whether you like that new syntax or not, is a matter of opinion. It is of course more type-safe and probably more approachable. That said, I find the verbosity a bit off-putting, although I chalk some of this up to Java being Java - other language implementations could be a bit nicer there. I also question the API design somewhat: regexes are inductively defined, there are a couple of primitives and a couple of operators that combine these primitives and the API doesn't make this very explicit by using the builder pattern. But ultimately, I'm more used to the way regular expressions are usually written, and for many tasks, that syntax is also more portable (e.g. regular expressions can be configuration which can be hugely useful for e.g. NLP tasks). For quick one-off text replacement tasks with very simple regexes I also think that this syntax would be way too cumbersome. Lastly, there are some people in the comments suggesting the use of parser combinators, BNF and similar formalisms / tools. Those might be an option for your use case, but they don't give you regular languages (although, sadly: regular expressions in most languages nowadays are not regular anymore). Having a regular language might be an actual requirement for whatever reason (e.g. constant memory usage).