5 ms·

So sad there is still no static metaprogramming. I've switched my career from a Flutter mobile dev over to backend, and there are still no updates on this an ut

So sad there is still no static metaprogramming. I've switched my career from a Flutter mobile dev over to backend, and there are still no updates on this an utterly important feature for Dart. This could've eliminated so much sickening codegen.

mathisfun123 3y ago
This doc was updated 3 weeks ago? https://github.com/dart-lang/language/blob/main/working/macros/feature-specification.md https://github.com/dart-lang/language/blob/main/working/macr... > This could've eliminated so much sickening codegen. Also this is funny because what do you think static metaprogramming is if not codegen? Templates macros etc are all codegen. They're just codegen you can't see (or easily steer either).
- ac130kz 3y ago
  It was really stuck at "in progress" for a looong time, and it's still in the working set, so it means that's going to take yet another 2-3 Dart releases and a few more to stabilize for production. > They're just codegen you can't see Yes, and that's exactly how it should have been in the first place. No need to run buggy services, no need to constantly juggle newly generated files.
  - mathisfun123 3y ago
    do you understand that things that you can't see still need to be juggled? the problems don't magically go away just because you can't see the artifacts. what happens is you lose complete control over how they're juggled and you retain as much control as the compiler owner deigns to give you (see generic in Go). please see all the pain of working templates in C++.
    - ac130kz 3y ago
      I do, I work with Rust templates and worked with C++ templates. Obviously, people aren't asking for such a granular level of metaprogramming.
      - mathisfun123 3y ago
        > Obviously, people aren't asking for such a granular level of metaprogramming. that `Obviously` is doing a lot of work there but more so i'm saying going from codegen facilities to static metaprogramming is a step in the wrong direction if the static metaprogramming is at the cost of the codegen.
- vsmenon 3y ago
  [ I work on Dart ] We're still working on this, and you can find updates in the language repo. One reason we're taking extra time here is that macros / static metaprogramming can blow up compile times and hot reload.
  - mathisfun123 3y ago
    that's fine - i'm not complaining i'm waiting patiently. keep going!
munificent 3y ago
We're actively working on static metaprogramming. It got slowed down during the lead-up to 3.0 because it was sort of all-hands-on-deck to get that set of features out and fully migrate stuff to null safety. Now that that's done, we're picking it back up. It's a particularly hard feature to work on because it touches everything. Some of the kinds of stuff you run into are like: * How do IDEs handle go-to-definition when the thing you're navigating to is generated through metaprogramming? * What is the API we expose to macros and how does that API evolve when the language changes? * If a macro adds a method to a class that shadows a top-level identifier, how does that interact with other method bodies in that class that might be referring to that identifier? * What happens to the user experience when a macro takes a really long time to run? Can users tell which macros are running slowly? How? * What happens when a macro throws an exception or otherwise fails? * How does hot reload work with macros? How does macro performance affect hot reload time? * What is the syntax for invoking a macro? What kinds of arguments can you pass to macros? Are they passed as values, raw syntax, meta-values? If they are passed as values, when are those values evaluated and in what context? * Are macros expressive enough for the use cases we have? Are they too powerful? What kinds of things should you be able to do with macros? What kinds of things should you not be able to do? * How does a user understand code that may be relying heavily on macros? * What is the user experience for authoring a macro? What developer tools do we give you? What is it like maintaining a package that exposes publicly usable macros? When the language changes, what do macro package authors have to do to keep their package working? Getting any of these answers wrong can really harm the whole user experience of the language, so it's just a big challenging ball of work with lots of stakeholders. We're making good progress and I'm really excited by everything Jake, Johnni, and Konstantin are doing, but it's definitely not something we want to rush.

mathisfun123 3y ago

This doc was updated 3 weeks ago? https://github.com/dart-lang/language/blob/main/working/macros/feature-specification.md https://github.com/dart-lang/language/blob/main/working/macr... > This could've eliminated so much sickening codegen. Also this is funny because what do you think static metaprogramming is if not codegen? Templates macros etc are all codegen. They're just codegen you can't see (or easily steer either).

ac130kz 3y ago
It was really stuck at "in progress" for a looong time, and it's still in the working set, so it means that's going to take yet another 2-3 Dart releases and a few more to stabilize for production. > They're just codegen you can't see Yes, and that's exactly how it should have been in the first place. No need to run buggy services, no need to constantly juggle newly generated files.
- mathisfun123 3y ago
  do you understand that things that you can't see still need to be juggled? the problems don't magically go away just because you can't see the artifacts. what happens is you lose complete control over how they're juggled and you retain as much control as the compiler owner deigns to give you (see generic in Go). please see all the pain of working templates in C++.
  - ac130kz 3y ago
    I do, I work with Rust templates and worked with C++ templates. Obviously, people aren't asking for such a granular level of metaprogramming.
    - mathisfun123 3y ago
      > Obviously, people aren't asking for such a granular level of metaprogramming. that `Obviously` is doing a lot of work there but more so i'm saying going from codegen facilities to static metaprogramming is a step in the wrong direction if the static metaprogramming is at the cost of the codegen.
vsmenon 3y ago
[ I work on Dart ] We're still working on this, and you can find updates in the language repo. One reason we're taking extra time here is that macros / static metaprogramming can blow up compile times and hot reload.
- mathisfun123 3y ago
  that's fine - i'm not complaining i'm waiting patiently. keep going!

munificent 3y ago

We're actively working on static metaprogramming. It got slowed down during the lead-up to 3.0 because it was sort of all-hands-on-deck to get that set of features out and fully migrate stuff to null safety. Now that that's done, we're picking it back up. It's a particularly hard feature to work on because it touches everything. Some of the kinds of stuff you run into are like: * How do IDEs handle go-to-definition when the thing you're navigating to is generated through metaprogramming? * What is the API we expose to macros and how does that API evolve when the language changes? * If a macro adds a method to a class that shadows a top-level identifier, how does that interact with other method bodies in that class that might be referring to that identifier? * What happens to the user experience when a macro takes a really long time to run? Can users tell which macros are running slowly? How? * What happens when a macro throws an exception or otherwise fails? * How does hot reload work with macros? How does macro performance affect hot reload time? * What is the syntax for invoking a macro? What kinds of arguments can you pass to macros? Are they passed as values, raw syntax, meta-values? If they are passed as values, when are those values evaluated and in what context? * Are macros expressive enough for the use cases we have? Are they too powerful? What kinds of things should you be able to do with macros? What kinds of things should you not be able to do? * How does a user understand code that may be relying heavily on macros? * What is the user experience for authoring a macro? What developer tools do we give you? What is it like maintaining a package that exposes publicly usable macros? When the language changes, what do macro package authors have to do to keep their package working? Getting any of these answers wrong can really harm the whole user experience of the language, so it's just a big challenging ball of work with lots of stakeholders. We're making good progress and I'm really excited by everything Jake, Johnni, and Konstantin are doing, but it's definitely not something we want to rush.