Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update on Dart macros and data serialization

medium.com

Post reply on HN
Print view View original

91–100 of 125 posts

Re: An update on Dart macros and data serialization

#91

Post by munificent »

chad1n wrote: post #55

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 probl…

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

Re: An update on Dart macros and data serialization

#92

Post by munificent »

anothername12 wrote: post #6

Why is it that Lisp family macros are easy to implement and use, but not so in other languages?

Lisp is dynamically typed and macros are syntactic. The macro gets in an AST and spits out an AST with little in the way of semantic information involved beyond maybe some identifier resolution.

Dart is a statically typed language and we wanted macros to be able to introspect over the semantics of the code the macro is applied to, not just the semantics. For example, if a macro is generating code for serialization, we wanted the macro to be able to ask "Does the type of this field implement JsonSerializable?". Answering that means being able to look up the type of the field, possibly walk its inheritance hierarchy, etc.

It's a very different problem from just "give me a way to add pretty loop syntax".

Re: An update on Dart macros and data serialization

#93

Post by eseidel »

miffy900 wrote: post #82
eseidel wrote: post #35

Earlier quoted context omitted.

[Flutter founder here.] I'm pretty sure we did look at C# (and certainly a whole bunch of other languages). I don't actually recall why we didn't use C# at the time. I remember Go binaries were waaay to big, JS (what we originally wrote Flutter in) startup time was way too slow on iOS, Swift was too deeply tied to Apple (the standard library was closed source at that time), etc. It's possible that C# was too verbose…

I don't think C# would've been a good fit for flutter in its early days, but definitely Flutter should no longer be tied to a single language like Dart. I think you should definitely consider stronger cross-language support.

I'm not sure what that would look like. Flutter mostly written in Dart itself (the framework, tooling, etc). The Flutter Engine (C++) is probably less than 1/3rd of Flutter, but could certainly be made portable to other languages if that were useful, but I suspect said languages would just fork it or write their own.

Re: An update on Dart macros and data serialization

#94

Post by esprehn »

cogman10 wrote: post #56
eseidel wrote: post #35

Earlier quoted context omitted.

[Flutter founder here.] I'm pretty sure we did look at C# (and certainly a whole bunch of other languages). I don't actually recall why we didn't use C# at the time. I remember Go binaries were waaay to big, JS (what we originally wrote Flutter in) startup time was way too slow on iOS, Swift was too deeply tied to Apple (the standard library was closed source at that time), etc. It's possible that C# was too verbose…

Assuming you were looking at the language 2016ish I could see why you'd rule out C#. That was the same year that MS first released C# core. For cross platform support mono was really the only way to go and it was second class. MS was just starting to get out of the mindset of putting the universe into the .Net framework and instead offering first class support for a broader 3rd party ecosystem. How Microsoft operates…

It was 2014, so even earlier than that.

Re: An update on Dart macros and data serialization

#95

Post by kazinator »

munificent wrote: post #90
kazinator wrote: post #65

> 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 ins…

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

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!

Re: An update on Dart macros and data serialization

#96

Post by esprehn »

eseidel wrote: post #54
paulddraper wrote: post #46

Earlier quoted context omitted.

I am curious as well. Despite the "not invented at Google" swipe * TypeScript wasn't invented at Google either, but adopted heavily. * Angular was the first major project ever to use TS. * And interestingly enough, Anders Hejlsberg contributed heavily to both.

Typescript is great! But doesn't get you away from running in a JS interpreter or JIT, which at least on iOS is very slow. We wrote the first 3 versions of Flutter in JS but eventually had to move off due to 10s+ startup times (we wrote a ton of JS). Once we moved to an ahead-of-time compiled language we could write as much code as we wanted and the user didn't have to compile it during launch on their device. Typesc…

These days Hermes is the answer to the JS and iOS startup issues. Of course it's a decade too late for flutter. :P

https://github.com/facebook/hermes

https://x.com/tmikov/status/1869945330638442651

Btw that Angular history is backwards. The first versions of angular were written in JS back in ~2009. jQuery was the most popular way to build web apps, and Angular provided a (very fancy) declarative data binding framework over it. Everything ran in your browser by inspecting DOM attributes.

Later in ~2014 they built a new framework on similar principles in TypeScript, but with an AOT compiler and called it "Angular 2". Then they retconed the original framework "AngularJS" and made the 2+ framework be just "Angular". In that era some Ads folks forked the Angular 2 framework and rewrote it in Dart and the two frameworks evolved separately since.

So there's really 3 separate "angular" frameworks...

Re: An update on Dart macros and data serialization

#97

Post by api »

mdhb wrote: post #43
api wrote: post #37

Earlier quoted context omitted.

I think Go would have been the most logical choice, given that it's Google.

I think you are missing the fact that Dart is actually an incredibly nice language to work with in a way that Go absolutely is not.

The problem is that it’s yet another language. It’s the cognitive load and the inability to easily reuse code across a project.

Re: An update on Dart macros and data serialization

#98

Post by munificent »

kazinator wrote: post #95
munificent wrote: post #90

Earlier quoted context omitted.

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

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

Re: An update on Dart macros and data serialization

#99

Post by kazinator »

munificent wrote: post #98
kazinator wrote: post #95

Earlier 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…

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.

Re: An update on Dart macros and data serialization

#100

Post by whoknowsidont »

CharlieDigital wrote: post #86
whoknowsidont wrote: post #77

Earlier quoted context omitted.

The improvements are great for people who have to or want to use C# for whatever reason? But how does that move the needle from other tech-stacks that are for more capable, especially on non-Windows environments (and please don't imply that C# is truly cross-platform, it's fine for web API's, it's not fine when dealing with actual system calls). If you're within the Windows garden, those tools certainly make sense to…

I'm not advocating it for every use case, I'm advocating it for use cases where it's a good fit (e.g. web APIs, backends where there's a need for multi-threaded code). For teams that need to move up from Node/JS/TS or augment Node/JS/TS, it's likely a better choice than say Rust or Go (nothing wrong with Go, but C# is going to be an easier ramp than Go for JS/TS devs IMO) I would not, for example, advocate it for web…

>I'm advocating it for use cases where it's a good fit

>I would not, for example, advocate it for web UIs or any UIs except for Windows desktop UIs

Well, the GP was talking about using C# for Flutter, a cross-platform product from desktop to web lol.

Post reply on HN