3 ms·

I still feel that it was a big mistake in retrospective that we ended up with serde style macros all over the place instead of getting introspection early on.

I still feel that it was a big mistake in retrospective that we ended up with serde style macros all over the place instead of getting introspection early on. The end result is ungodly amounts of quite convoluted code that in parts is not even compatible with each other. It also greatly restricts what you can do, because you cannot be conditional on the thing you're generating for. I'm not sure if the C++ solution proposed is the right abstraction, but I feel very confident in saying that Rust's is not the gold standard that one should strive for.

steveklabnik 2y ago
Full agreement. Proc macros are an accident of history in many ways. I would encourage new language authors to go straight towards reflection instead.
- cogman10 2y ago
  Really makes me appreciate Java/kotlin's annotation processors. They are much cleaner/clearer APIs for writing compile time generated software and the entire ecosystem has benefited from them.
  - Twisol 2y ago
    I, uh, cannot in good conscience call Java's annotation processing APIs "clean" or "clear"; the way they interact with the multi-round processing model, and in particular make it extremely hard to build well-behaved processors that can cope with parts of the compile-time code graph not existing until later rounds, has baffled me for a long time. Despite their definite flaws, though, I have to agree: compile-time code generation via annotation processing is something I think we should do more of (and invest more time into better tools for it).
    - cogman10 2y ago
      > in particular make it extremely hard to build well-behaved processors that can cope with parts of the compile-time code graph not existing until later rounds, has baffled me for a long time. I'm not exactly sure how you can really make this particular problem better when working with compile time code generation. But what I'd say WRT cleaner and clearer, Java and Kotlin both expose much higher level type information than is available in rust's proc macros. That's mostly what I meant by cleaner and clearer. Without needing to pull in weirdo not-quite-third-party libraries, you can reflect on and generate for all sort of different type information. It seems to me that something like this should be possible with rust given its early transformation into high level bytecode. But I could see why the rust devs have pushed back on doing that as it'd really lock in features they might not want to lock in.

steveklabnik 2y ago

Full agreement. Proc macros are an accident of history in many ways. I would encourage new language authors to go straight towards reflection instead.

cogman10 2y ago
Really makes me appreciate Java/kotlin's annotation processors. They are much cleaner/clearer APIs for writing compile time generated software and the entire ecosystem has benefited from them.
- Twisol 2y ago
  I, uh, cannot in good conscience call Java's annotation processing APIs "clean" or "clear"; the way they interact with the multi-round processing model, and in particular make it extremely hard to build well-behaved processors that can cope with parts of the compile-time code graph not existing until later rounds, has baffled me for a long time. Despite their definite flaws, though, I have to agree: compile-time code generation via annotation processing is something I think we should do more of (and invest more time into better tools for it).
  - cogman10 2y ago
    > in particular make it extremely hard to build well-behaved processors that can cope with parts of the compile-time code graph not existing until later rounds, has baffled me for a long time. I'm not exactly sure how you can really make this particular problem better when working with compile time code generation. But what I'd say WRT cleaner and clearer, Java and Kotlin both expose much higher level type information than is available in rust's proc macros. That's mostly what I meant by cleaner and clearer. Without needing to pull in weirdo not-quite-third-party libraries, you can reflect on and generate for all sort of different type information. It seems to me that something like this should be possible with rust given its early transformation into high level bytecode. But I could see why the rust devs have pushed back on doing that as it'd really lock in features they might not want to lock in.