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

61–70 of 125 posts

Re: An update on Dart macros and data serialization

#61

Post by zigzag312 »

eseidel wrote: post #35
zigzag312 wrote: post #17

They should have just use C# for Flutter. Without investing significant time, like they did with Dart, they would have a language with a much bigger ecosystem that is faster, already has compile time code generation and better support for data than Dart. It supports ahead-of-time compilation and hot-reload. The only feature missing in C# is compilation to JS, but with WASM is that really needed? Biggest downside of C…

[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 guess that at the time you started developing Flutter C#'s hot reload, source generators and NativeAOT compilation didn't yet exist or were just introduced and incomplete.

Re: An update on Dart macros and data serialization

#62

Post by jdonaldson »

Macros give their own kind of power, and it's a tough call to give that up for runtime hot-reloading. Languages like Haxe have macros, but also have hot reloading capabilities that typically are supported in certain game frameworks. You probably don't want to mix them together, but it's also a good development process to have simpler compilation targets that enable more rapid R&D, and then save macros for larger/more comprehensive builds.

https://haxe.org/manual/macro.html

https://github.com/RblSb/KhaHotReload

Re: An update on Dart macros and data serialization

#63

Post by eseidel »

Decabytes wrote: post #51

> Runtime introspection (e.g., reflection) makes it difficult to perform the tree-shaking optimizations that allow us to generate smaller binaries. Does anyone have any more information on How Dart actually does Tree Shaking? And what is "Tree Shakeable"? This issue is still open on Github https://github.com/Dart-lang/sdk/issues/33920 . I think this quote accurately sums things up > In fact the only references I can…

I don't have a full answer for you, but I know a little. I've hacked on the Dart compiler some, but my relationship with Dart has mostly been as a creator of Flutter and briefly Eng Dir for the Dart project.

Dart has multiple layers where it does tree shaking.

The first one is when building the "dill" (dart intermediate language) file, which is essentially the "front-end" processing step of the compiler which takes .dart files and does amount of processing. At that step things like entire unused libraries and classes are removed I believe.

When compiling to an ahead of time compiled binary (e.g. for releasing to iOS or Android) Dart does additional steps where it collects a set of roots and walks from those roots to related objects in the graph and discards all the rest. Not unlike a garbage collection. There are several passes of this for different parts of the compile, including as Dart is even writing the binary it will drop things like class names for unused classes (but keep their id in the snapshot so as not to re-number all the other classes).

I have no experience with tree shaking in the dart2js compiler, but there are experts on Discord who might be able to answer: https://github.com/flutter/flutter/blob/master/docs/contribu...

What exactly all this means as a dev using Dart, I don't know. In general I just assume the tree shaking works and ignore it. :)

The Dart tech lead has done some writings, but none seem to cover the exact details of treeshaking: https://mrale.ph/dartvm/ https://github.com/dart-lang/sdk/blob/main/runtime/docs/READ...

Re: An update on Dart macros and data serialization

#64

Post by eseidel »

zigzag312 wrote: post #61
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 guess that at the time you started developing Flutter C#'s hot reload, source generators and NativeAOT compilation didn't yet exist or were just introduced and incomplete.

We started Flutter in 2014 and made the decision to switch to Dart in ~Jan 2015 iirc.

Re: An update on Dart macros and data serialization

#65

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

Re: An update on Dart macros and data serialization

#66

Post by rafaelmn »

eseidel wrote: post #35
zigzag312 wrote: post #17

They should have just use C# for Flutter. Without investing significant time, like they did with Dart, they would have a language with a much bigger ecosystem that is faster, already has compile time code generation and better support for data than Dart. It supports ahead-of-time compilation and hot-reload. The only feature missing in C# is compilation to JS, but with WASM is that really needed? Biggest downside of C…

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

.NET is huge compared to Dart and every hot reload I've seen was complete garbage compared to what you get in Flutter.

Anyone who worked with the mobile .NET and Flutter would see Dart/Flutter DX as something unreachable for .NET, it's a terrible experience like any other .NET cross compilation I've tried (Blazor, Silverlight).

I'm not a big fan of Dart as a language but it really was a great choice that allowed amazing DX, Flutter hot reload feelt better than JS/HTML.

Re: An update on Dart macros and data serialization

#67

Post by eseidel »

paulddraper wrote: post #59
eseidel wrote: post #54

Earlier quoted context omitted.

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…

Sorry, I was unclear. I didn't mean to necessarily suggest TS as a candidate for Dart's goals. (Though there is STS...) I meant to point out that you can't just assume a priori it was NIH syndrome, as Google's heavy adoption of TS is a counterexample.

Makes sense. Google is a very large and diverse place. (And sometimes a lot of unpleasant infighting and politicking around tech choices.)

Re: An update on Dart macros and data serialization

#68

Post by DannyBee »

paulddraper wrote: post #46
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 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.

There are lots of good examples of adoption despite non invention.

Ironically, Typescript is not the best one. I can go into great detail - i was overseeing production programming languages at Google at the time, but getting to Typescript (which was the right choice) took a lot.

For most things, even things that seem to be contentious in the broader developer world, internal developer infrastructure teams were often relatively agnostic on choice as long as we had the resources to do it right (IE deal with migrations, etc). You'd have to push people to be meaningfully objective in evaluations, but once they realized you were not going to let them get away with nonsense, you got reasonable evaluations and options. Not always (can't avoid zealots at this scale), but a lot of the time.

But Typescript vs Dart vs Closure (GWT and a few other things were in there somewhere, too) was just particularly contentious for $reasons.

Re: An update on Dart macros and data serialization

#69

Post by CharlieDigital »

whoknowsidont wrote: post #58
zigzag312 wrote: post #17

They should have just use C# for Flutter. Without investing significant time, like they did with Dart, they would have a language with a much bigger ecosystem that is faster, already has compile time code generation and better support for data than Dart. It supports ahead-of-time compilation and hot-reload. The only feature missing in C# is compilation to JS, but with WASM is that really needed? Biggest downside of C…

>They should have just use C# for Flutter. Dear lord no. We don't need more C# in the world. >It supports ahead-of-time compilation and hot-reload. In name only. Doesn't really well in practice. Go and just look for "C# hot reload not working" in any search engine and look at the variety of contexts it just simply does not work with no resolution.

C# is a fantastic language that has, in recent years, evolved very quickly for the better. Nice mix of object and functional drawing a lot of influence from F#.

It shares a lot of language constructs with TypeScript (and by extension, JS) and has been converging with each release so I'm often surprised that people hate on it or that more startups don't reach for it if they are on Node with TS.

Same syntax for key language constructs like async-await, try-catch-finally, generics, etc.

Hot reload works pretty well (at least in the contexts that I use .NET (backend APIs)); a lot of the issues were from the early days. `dotnet watch` has been very much usable for the last few years.

Re: An update on Dart macros and data serialization

#70

Post by codemac »

lolinder wrote: post #21
codemac wrote: post #18

Earlier quoted context omitted.

> in Scheme you can redefine `define` to be number 5. This is like asking "what if your coworker named all errs as `ok`" so everything was `if ok { return errors.New("Not ok!!"); }`. It's possible but no one does it. This is why `defmacro` and `gensym` in common lisp are awesome, and similarly why Go's warts don't matter. Much of programming language ugliness is an "impact x frequency" calculation, rather than one or…

"No one does it" is extremely relative. Take your closing remark about JavaScript: I don't run into JS warts very often at all, and I'm a professional web developer who works in it day in and day out. I guess my team just doesn't do dumb JS stuff? But apparently lots of other people do run into them regularly, so I believe that such things do exist. By the same token, I've heard countless reports of people struggling…

ah you misunderstand me.

I don't mean "do dumb stuff", I mean I've literally never seen anyone redefine the `define` keyword in any code.

With javascript, I do see people use `===` frequently. It's a wart of the language that the operator even exist. It's not "dumb" to use it - it's how frequently are you assaulted with the bugs of the language (not bugs in your code).

Post reply on HN