Graphical User Interface Using Flutter in Embedded Systems [pdf]

> Also dart is a real PITA coming from typescripts which is basically c#.

That's surprising to me. Coming from Ruby Dart was great. Not better, but when you are expecting a tuned up javascript Dart was such a nice surprise. I'd have expected it'd be the same for someone coming from C#. You worked with a current version and gave it a fair shot?

I'm in the Flutter is great camp. The UI you produce with it work great, and the whole process is great. Very powerful and at the same time manageable, a smart small concept at its core, with much around it that makes it powerful. Combine it with GetX and the code you get can also be really nice.

But for Linux? No way, not until they have got a proper beta that is not tied to snap. But maybe Sony is working on that and showing it here? Or I'm just not aware that this is not a real requirement, despite the website making it sound that way?

> 1. Dart is garbage-collected;

Yup. Most languages used for UI programming these days are. JS and C# are probably the biggest two. UI programming is at a really interesting intersection between two difficult constraints:

* Much of the work is subjective, exploratory, and frequently-changing. It's hard to evaluate whether a UI looks and feels right until you code it up and try it. When you do, you often realize you need to change things. Also, product people really like to "refresh" application UIs frequently so there's a ton of churn. All of this means that developer productivity is absolutely paramount. You need to be able to make small iterative changes quickly to evaluate them, and you need to be able to do sweeping re-writes efficiently. That means you want a high-level language and GC is a big part of that.

* At the same time, the program is real-time interactive software running on user hardware that you don't control. So just like games, execution performance and latency is critical. A slow language implementation can degrade the application's appeal in ways that materially affect its success.

Balancing those is hard. Fortunately, people have been hacking on GCs for decades and have gotten really good at them. The Dart VM's garbage collector has been designed from day one for soft-realtime interactive performance. It's generational with a very fast nursery allocator and collector, doesn't stop the world, and (I believe) can do a full collection in the background.

Also, the language itself was somewhat designed to be GC friendly. Unlike dynamically typed languages like JS, object shape doesn't change at runtime so an instance is only ever a single allocation.

> 2. Dart has optional typing, which is to say it supports type hints but is essentially dynamically rather than statically typed.

As my colleague mraleph said, this hasn't been true for a couple of years, though it tends to take a long time for knowledge about this to percolate through the world. Dart is now a typical statically-typed language very similar to C# and Scala.

> But GC isn't just about overhead (although that is a concern). It's about predictability of performance. It's about tuning the VM and the characteristics of STW GC pauses (if any).

Exactly right. The Dart VM was always intended for client-side applications, so it's designed around low latency performance.

It could very well be PEBKAC, client-side decorations make being coordinate system aware much more important. If your code assumes everything's in drawable coordinates, it'll work in a top-level window on X11, but may break when Wayland w/CSD shifts things.

That slide is potentially quite damaging to GTK+'s reputation, to not even provide a way for us to independently verify the results is frustrating.