[kazinator]

> Semantic introspection, unfortunately, turned out to introduce large compile-time costs which made it difficult to keep stateful hot reload hot.

They must have done something wrong. Macros are expanded when you ahead-of-time compile your code, which doesn't take place in the run-time environment where you hot load, but in the build environment. It doesn't matter whether the macro are simple, or whether they can inspect lexical environments and look up type info and whatnot.

Compile-time costs should never factor into hot reload, because the stuff being loaded should already be compiled.

Maybe they aren't explaining it; there could be certain semantic problems preventing existing state from being re-used on what should be a hot reload.

Macros create certain issues in reloading. If you change a macro such that the expansion requires different run-time support which is incompatible with existing expansions, you have problems. One option may be to reload all the code which depends on those macros, so that everything cuts over to the new run-time support. If you need to support a mixture: hot-reloaded modules using the new versions of the macros, side by side with code made using the old versions, then the old version of the run-time support has to coexist with the old.

If the run-time support for the macros is something which manages state that needs to be preserved on reloads, then that can cause difficulties. The old and new macro expansions want to appear to be sharing the same state, not different silos.

[munificent]

> Macros are expanded when you ahead-of-time compile your code, which doesn't take place in the run-time environment where you hot load, but in the build environment.

The user experience with hot reload is:

1. They hit "run".

2. The compiler compiles the app.

3. The app starts running on their device.

4. They change some code in their IDE.

5. They click "hot reload".

6. The compiler compiles the changed code.

7. The IDE sends the updated code to the running app.

8. The runtime loads the changed code.

9. They see the changed behavior in their running app.

Steps 6-8 determine the total time between "user requests a hot reload" and "user sees their updated app". Compilation doesn't happen on the device, but it still takes time and is in the critical path for that experience.

Making the compiler slower makes hot reload slower. We measure hot reload time in milliseconds, so it doesn't take much for us to consider it an unacceptable performance regression.

[kazinator]

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!

[munificent]

> 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 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. :)

[markdog12]

> 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.

[kazinator]

You literally cannot get your thumb under your ass in milliseconds to sit on it, unless you're the Olympic record holder for that sporting event.

You can't change your focus from the window where you are editing the code to the window where you are interacting with the app in milliseconds. Maybe triple digit milliseconds at best, not double, let alone single. Well, double may be within reach, if it's hot-keyed.