| 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, unless you change the macros such that everything that uses them has to be recompiled, you still have the benefit of incremental compilation and hot reloading. E.g. recompiling one just one file-with-macros out of hundreds that don't get recompiled. > We measure hot reload time in milliseconds It takes seconds to minutes to make the code change, but when you hit the hot-key to deploy it to the target, it's gotta compile and upload in milliseconds? That's just a silly requirement that will leave your compiler development hamstrung. I can't even type this comment without at times experiencing character delays that are certainly more than single digit milliseconds. :) A conclusion like "our users require hot reloads to be milliseconds, end-to-end including compilation" deserves to be researched among the user base, because I don't suspect most devs need the times to be quite that low. They are building a program, not trying to avoid getting fragged in a multi-player shooter! |
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 application time was entirely pay as you go, then, yes, it would be feasible. But it impacted compiler performance worse than that.
> It takes seconds to minutes to make the code change, but when you hit the hot-key to deploy it to the target, it's gotta compile and upload in milliseconds?
Yup! Those seconds to minutes are meaningful time well spent by the user thinking about their program and the problem. Those milliseconds are just them sitting on their thumb getting mad at the machine.
> deserves to be researched among the user base, because I don't suspect most devs need the times to be quite that low.
I would suggest to you that after working on Flutter for nearly a decade, conducting user surveys every single quarter, gathering metrics from our tool usage (opt in) and lots of other UX research, that we do have a pretty good idea of what our user base wants in regards to performance. :)