tree-sitter-rust VS tree-sitter-python

Yes. It's typically a fair bit slower than a hand-coded parser. The idea sounds great until you're working on a codebase with 2 million LOC. At that point, the speed of a cold parse is most important, whereas TS is designed for fast re-parsing of a single file. These aren't great numbers but the Rust TS parser is reportedly 2x slower than rustc's https://github.com/tree-sitter/tree-sitter-rust. It's no surprise that you just use the faster option if it's convenient.

Notes for anyone interested, there is this PR https://github.com/tree-sitter/tree-sitter-rust/pull/128, which merges successive doc comments.

Tree-sitter is a fantastic parser generation and incremental parsing library, that supports Rust language bindings and has an available parser Rust tree-sitter-rust.

You can see a much more in-depth version at https://github.com/tree-sitter/tree-sitter-typescript or https://github.com/tree-sitter/tree-sitter-rust

I'll be really interested to see what folks end up preferring once nvim 0.5 ships with treesitter support. Do folks have any experience with the Rust grammar?

i dont see the issue reported in the python parser: https://github.com/tree-sitter/tree-sitter-python/issues

How can we add different highlight for __dunder__ methods a.k.a. magic methods? Is there a TS highlight group for that? I know that in tree-sitter-python there is pythonTSConstructor for __init__ method that I can customize, but I couldn't figure out for other magic methods.

You could try elisp-tree-sitter as soon as this issue is closed.