[deleted]
An update on Dart macros and data serialization
121–125 of 125 posts
Re: An update on Dart macros and data serialization
#122Good. Dart already has good support for code-generation. It would just encourage package authors and app developers to waste their time golfing.
It is incredibly slow though. I have a project with 40k lines of code which takes a minute to generate on an m1. It's a far cry from incremental compilation. It's enough that I generally avoid adding anything new that would require generation.
You should be able to leverage generate_for in your build.yaml with include/exclude to reduce those build times significantly. You should be able to get it back down to a few seconds including building the graph and then you should be able to just run watch instead of build.
It may be worth mentioning that build_runner's graph contains every single asset that might be generated. So when selecting what's included and excluded you can reduce the graph size dramatically.
Re: An update on Dart macros and data serialization
#123Hi, I work on Dart and was one of the people working on this feature. Reposting my Reddit comment to provide a little context: I'm bummed that it's canceled because of the lost time, but also relieved that we decided to cancel it. I feel it was the right decision. We knew the macros feature was a big risky gamble when we took a shot at it. But looking at other languages, I saw that most started out with some simple m…
Would you happen to have any feel for / comparative docs around how Java does all this? Java has had compile-time metaprogramming for a very long time, integrated with IDEs (well. eclipse), the type system, hot reloading, AOT, etc. It seems like one worth looking closely at, since most are rather simple in comparison (e.g. a huge amount are syntax-based and don't have in-progress type information).
Though it would not surprise me at all if it was considered too slow to adopt. I don't remember compile-time performance issues with it when I did Java work, but I was definitely not paying close attention, and the ecosystem strongly prefers runtime shenanigans in general.
Re: An update on Dart macros and data serialization
#124Hi, I work on Dart and was one of the people working on this feature. Reposting my Reddit comment to provide a little context: I'm bummed that it's canceled because of the lost time, but also relieved that we decided to cancel it. I feel it was the right decision. We knew the macros feature was a big risky gamble when we took a shot at it. But looking at other languages, I saw that most started out with some simple m…
Sounds like performance is the biggest issue. I'm guessing the macros need to run after every keystroke. That creates big time constraint that while nice it's not really needed. Due to AOT compilation, some form of (pre)compile time code generation is needed, but it doesn't need to be macros. It doesn't need to be instantaneous, but it also shouldn't take minutes. Adding features directly into the language removes th…
IMO it would make the most sense if code generation was integral part of the dart build system. Few years ago I described shortcomings of build_runner on github https://github.com/flutter/flutter/issues/63323, not much changed afaik.
Re: An update on Dart macros and data serialization
#125Earlier quoted context omitted.
Firstly, that's a developing user of the language, not the end user of the application. Secondly, any compilation delay they experience affects all their iterative development scenarios, including a complete application restart for each run. If they wrote the macros themselves that are slowing down compilation that much, it is their self-inflicted problem. Even if macros are slowing down compilation noticeably, unles…
> Firstly, that's a developing user of the language, not the end user of the application. Yes, hot reload is a developer feature in Dart, not an end user feature. > If they wrote the macros themselves that are slowing down compilation that much, it is their self-inflicted problem. The compile time impact we saw, unfortunately, wasn't entirely linear in the amount of macro applications that a user had. If macro applic…
> I would suggest to you that after working on Flutter for nearly a decade
Did you just ask Flutter users? We've been using Dart for our company's stack for years, no Flutter. It seems you just took the Flutter dev experience into account. This makes this decision all the more disappointing to us.