The confusion here is because Pest is not, in fact, a parser. It's a parser generator: you can use it to generate parsers (maybe even a parser for Rust), but it is not in itself a parser.

A better title would be "Pest - Fast, modern parser generator for Rust".

One cool thing is that rather than the parser generation being a standalone tool, it's written using Rust's macro system. Normal parser generators use some sort of command line tool to generate say C code which can then be used like any other library. Here, there's no need for generated code, because the Rust macro system generates it on the fly.

Exactly what I came into this thread expecting. Was curious why when it looks like there's already great IDE support for Rust with existing tools.

There's actually a parser for rust called syn, and it's very useful for procedural macros, as the current API exposes a stream of tokens, not a full AST.

To elaborate a bit on that, exposing an AST directly means that you're tied to that version of the AST; this was considered really hard for compatibility over versions. Token streams are much easier to define an interface for, and more flexible: you're not just stuck with whatever AST representation we'd have given you.

For example: https://doc.rust-lang.org/book/first-edition/procedural-macr...

I agree. I guess I was trying hard to suggest the fact that it can be used _with_ Rust and not the fact that it is written _in_ Rust.

OK we've attempted to make a more accurate title above.

Yes this is no doubt the current implication. I was expecting something like racer.