[chad1n]

Sounds like a good thing overall, my biggest annoyance when I was writing a flutter app was the codegen for annotations (which sure it's better iteratively, but the first one was taking minutes), but if you move these seconds that happen once in a while to seconds during "hot" reload, you're just losing. Honestly, I think they should try to come with a faster codegen, maybe write it in c++ or rust and fix these problems, because macros aren't a silver bullet. They introduce complexity, a new "thing to learn" and sometimes lead to Turing complete machines.

[munificent]

> I think they should try to come with a faster codegen, maybe write it in c++ or rust and fix these problems

Language execution speed isn't the fundamental blocker for code generation in Dart. Dart isn't quite as fast as C++ or Rust, but it's in roughly the same ballpark as other statically typed GC languages like C#, Java, and Go.

The performance challenges in code generation are more architectural and are around cache invalidation, modularity, and other tricky stuff like that.

[brookman64k]

I belive there are many low hanging fruits to improve the speed. In my project the code generation took more than 3 minutes. This is rather annoying if you have just renamed a field in a single “freezed“ class. We could speed up this process by 3x by hacking together a script which greps all .dart files for the relevant annotations like “@freezed“ and then only feeds those to the build_runner via a on-the-fly-generated config file.

[TsonnReopev]

https://github.com/dart-lang/build/issues/3800 is where the "low hanging fruit search" is happening :)

[munificent]

Agreed, there is a lot of opportunity to improve build_runner. I hope now that we've freed up a lot of engineering resources from macros that we can dig into that some.