> "[Define some quirky DSL hackery] [Implement a bunch of code using it]" This is the use case for macros, and Rust macros are at least as good as C macros for

> "[Define some quirky DSL hackery] [Implement a bunch of code using it]" This is the use case for macros, and Rust macros are at least as good as C macros for my common use cases. It's true they are more limited than Scheme macros, and also fairly different from C++ template metaprogramming. Rust macros aren't perfect, and they'll certainly improve as the language matures. Also, for cases where a compiler plugin is needed, I'm not sure why having it in a separate file is such a deal-breaker. Opening multiple editor tabs/windows/frames has never seemed that annoying to me. > The example code in the linked article is simply ugly. Ugly APIs are bad, even (especially) for subtle features. Yeah, Rust syntax extensions at this point are basically just reaching into the guts of the compiler and using APIs that were never meant to be public. That's why they're not part of Rust 1.0, and won't become part of the stable language any time in the near future. Right now I see them partly as a way of prototyping compiler/language features. Hopefully in the long term they will grow into (or be replaced by) something with a stable, well-designed API that still exposes most or all of the current power. By the way, Servo uses Rust macros, Rust syntax extensions, and two different Python script for code generation. (One is a fork of Gecko's WebIDL parser for generating DOM bindings; the other pre-processes a source file writen as a Mako template.)