5 ms·

Honestly I don't get the appeal of Dart/Flutter for this use case for two major reasons: 1. Dart is garbage-collected; and 2. Dart has optional typing, which

by cletus 6y ago

Honestly I don't get the appeal of Dart/Flutter for this use case for two major reasons: 1. Dart is garbage-collected; and 2. Dart has optional typing, which is to say it supports type hints but is essentially dynamically rather than statically typed. This presentation claims low overhead so I'm open to be proven wrong here. I wonder how much of that (if true) is Flutter and how much is Wayland (over X). I'd really like to see some nontrivial apps in this, React Native, Qt, GTK and the like. 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).

kettro 6y ago
An important distinction is Embedded and Real-time. Embedded is the all-encompassing tent, while Real-time is a subset thereof. Embedded includes things with GUIs, like fridges. We're not dealing with 128k of RAM. These can run basic GC'd apps just fine. Pauses really aren't any more of a concern than on desktop, or even less so.
- JoeAltmaier 6y ago
  My experience is not this. I've never seen an embedded app with GC. And embedded is usually dog slow processor running at minimum clock, to save power. So pauses are 10X or more the issue re: desktop.
  - black3r 6y ago
    > And embedded is usually dog slow processor running at minimum clock, to save power. It used to be like this for a long time, but nowadays the market is moving towards stronger embedded CPUs, either just because they are affordable (raspberry pi), or the power is actually wanted for something (e.g. nvidia jetson for video processing and AI)
    - dathinab 6y ago
      Yes I mean I just did some quick price research and I (as a private person) can buy a Quad core Cortex-A53 for just 5.20$... And a Raspbery PI Zero (no WLAN) for 12€.
      - JoeAltmaier 6y ago
        Regardless, if a lesser module for $4.50 will squeak by, then that's what the designer should specify. And the programmer will make do.
  - dathinab 6y ago
    Embedded is a very wide field. It includes anything from thinks like (home) routers and TV set-top boxes to <8MHz 8bit processors. Embedded devices which have a UI which is not just some simple segment display (e.g. touch screen) are today not seldomly comparable with low end smartphones and tend to not be battery based. I mean think about how cheap a 1+GHz ARM chip has become today.
    - JoeAltmaier 6y ago
      I program complex color displays, wifi on devices with 1GHz clock. Still on batteries; still slow and speed/latency matter. A lot. Embedded is always the smallest device possible for the application. Else the designer made a mistake. So its always critical speed/space.
  - wahern 6y ago
    Lua is not uncommon on embedded devices, even the slow industrial kind, as opposed to "embedded" devices with desktop- and server-class processors. Independent of fancy algorithms, GC complexity, cost, and latency are straight-forward functions of the number of managed objects. It's not uncommon to use a "glue" language like Lua in a manner where the runtime only juggles a small number of objects, which in turn encapsulate and manage most of the application data independent of the garbage collector. Even in applications with complex, cyclic object graphs (i.e. the ones were GC makes sense), you can usually push the problematic edges into a small number of GC'd objects. Language GC (mark & sweep, reference counting, etc) can at least in principal provide a zero marginal cost benefit. Java, JavaScript, and Python reflect poorly on the usability of GC because they're extremely object heavy and weren't designed with embedding in mind. Scalars and aggregates didn't figure prominently into their design, including C FFI (to the extent C FFI was even a consideration of their original language semantics). And they're too liberal with heap allocation in both their semantics and implementation, inducing unnecessary object churn.
  - munificent 6y ago
    "Embedded" means different things to different people. Back when I was a game developer at EA, Madden and many other sports console games all shipped using Flash (!) interpreters with full GC. These were games running on PS2, NGC, XBox, etc.
    - JoeAltmaier 6y ago
      Sure it does. But if its possible to choose a cheaper hardware chipset and not do GC then that's likely the correct choice. Or the designer has made a mistake (BOM cost higher than it needs to be).
      - mwcampbell 6y ago
        Is it always a mistake for the BOM cost to be higher than it hypothetically could be? Can't a designer reasonably trade off some BOM cost for other things such as development cost?
- layoutIfNeeded 6y ago
  >These can run basic GC'd apps just fine LOL, this explains why every embedded GUI I encounter in these "smart" devices is awfully sluggish and a pain to use, delivering 5fps at most. Thx for the clarification!
  - fmakunbound 6y ago
    Don’t know why you’re getting voted down... One only has to pick the same app, implemented natively on comparable iPhone and Android hardware to see that the underlying language runtime, that’s NOT garbage collected, is the one with the buttery-smooth UI. With JS “native” or web whatever, it’s even more pronounced on the SAME hardware.
    - layoutIfNeeded 6y ago
      Yep. Last week I had the joy of checking the infotainment system of my friend’s new car, for which Renault thought it was a good idea to use this Android fork or whatever, with a touchscreen interface of course. It was comically bad! The latency, the framerate, the whole user experience was utter crap. If they had literally glued a 2G iPhone from 2007 to the dashboard it would have been better than this embedded Android GUI. And I refuse to believe that the hardware in a 2020 executive car is less performant than a phone from 13 years ago, so the culprit has to be the software...
mraleph 6y ago
> 2. Dart has optional typing, which is to say it supports type hints but is essentially dynamically rather than statically typed. Dart has not been optionally typed since Dart 2 (released in 2018).
munificent 6y ago
I work on the Dart team. > 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.
dathinab 6y ago
Embedded devices which have a UI are by now normally so fast that garbage-collection doesn't matter at all. Similar you tend to not need to turn the GC at all for writing UI applications like that, the defaults are just good enough. Lastly while dart can be dynamically typed (EDIT: it's opt-in dynamic typing instead of opt-in static typing) it's typed statically "good enough". I love static typing (e.g. rust, scala) but in difference to type script I haven't run into any major gotchas when using dart. It feels very Java-ish just without the bad parts of java tbh.
1ark 6y ago
I would have thought embedded generally meant a bit more streamlined than running Dart as well. Something like https://lvgl.io https://lvgl.io (which I just heard about yesterday, thanks HN!)

by cletus 6y ago

kettro 6y ago

An important distinction is Embedded and Real-time. Embedded is the all-encompassing tent, while Real-time is a subset thereof. Embedded includes things with GUIs, like fridges. We're not dealing with 128k of RAM. These can run basic GC'd apps just fine. Pauses really aren't any more of a concern than on desktop, or even less so.

JoeAltmaier 6y ago
My experience is not this. I've never seen an embedded app with GC. And embedded is usually dog slow processor running at minimum clock, to save power. So pauses are 10X or more the issue re: desktop.
- black3r 6y ago
  > And embedded is usually dog slow processor running at minimum clock, to save power. It used to be like this for a long time, but nowadays the market is moving towards stronger embedded CPUs, either just because they are affordable (raspberry pi), or the power is actually wanted for something (e.g. nvidia jetson for video processing and AI)
  - dathinab 6y ago
    Yes I mean I just did some quick price research and I (as a private person) can buy a Quad core Cortex-A53 for just 5.20$... And a Raspbery PI Zero (no WLAN) for 12€.
    - JoeAltmaier 6y ago
      Regardless, if a lesser module for $4.50 will squeak by, then that's what the designer should specify. And the programmer will make do.
- dathinab 6y ago
  Embedded is a very wide field. It includes anything from thinks like (home) routers and TV set-top boxes to <8MHz 8bit processors. Embedded devices which have a UI which is not just some simple segment display (e.g. touch screen) are today not seldomly comparable with low end smartphones and tend to not be battery based. I mean think about how cheap a 1+GHz ARM chip has become today.
  - JoeAltmaier 6y ago
    I program complex color displays, wifi on devices with 1GHz clock. Still on batteries; still slow and speed/latency matter. A lot. Embedded is always the smallest device possible for the application. Else the designer made a mistake. So its always critical speed/space.
- wahern 6y ago
  Lua is not uncommon on embedded devices, even the slow industrial kind, as opposed to "embedded" devices with desktop- and server-class processors. Independent of fancy algorithms, GC complexity, cost, and latency are straight-forward functions of the number of managed objects. It's not uncommon to use a "glue" language like Lua in a manner where the runtime only juggles a small number of objects, which in turn encapsulate and manage most of the application data independent of the garbage collector. Even in applications with complex, cyclic object graphs (i.e. the ones were GC makes sense), you can usually push the problematic edges into a small number of GC'd objects. Language GC (mark & sweep, reference counting, etc) can at least in principal provide a zero marginal cost benefit. Java, JavaScript, and Python reflect poorly on the usability of GC because they're extremely object heavy and weren't designed with embedding in mind. Scalars and aggregates didn't figure prominently into their design, including C FFI (to the extent C FFI was even a consideration of their original language semantics). And they're too liberal with heap allocation in both their semantics and implementation, inducing unnecessary object churn.
- munificent 6y ago
  "Embedded" means different things to different people. Back when I was a game developer at EA, Madden and many other sports console games all shipped using Flash (!) interpreters with full GC. These were games running on PS2, NGC, XBox, etc.
  - JoeAltmaier 6y ago
    Sure it does. But if its possible to choose a cheaper hardware chipset and not do GC then that's likely the correct choice. Or the designer has made a mistake (BOM cost higher than it needs to be).
    - mwcampbell 6y ago
      Is it always a mistake for the BOM cost to be higher than it hypothetically could be? Can't a designer reasonably trade off some BOM cost for other things such as development cost?
layoutIfNeeded 6y ago
>These can run basic GC'd apps just fine LOL, this explains why every embedded GUI I encounter in these "smart" devices is awfully sluggish and a pain to use, delivering 5fps at most. Thx for the clarification!
- fmakunbound 6y ago
  Don’t know why you’re getting voted down... One only has to pick the same app, implemented natively on comparable iPhone and Android hardware to see that the underlying language runtime, that’s NOT garbage collected, is the one with the buttery-smooth UI. With JS “native” or web whatever, it’s even more pronounced on the SAME hardware.
  - layoutIfNeeded 6y ago
    Yep. Last week I had the joy of checking the infotainment system of my friend’s new car, for which Renault thought it was a good idea to use this Android fork or whatever, with a touchscreen interface of course. It was comically bad! The latency, the framerate, the whole user experience was utter crap. If they had literally glued a 2G iPhone from 2007 to the dashboard it would have been better than this embedded Android GUI. And I refuse to believe that the hardware in a 2020 executive car is less performant than a phone from 13 years ago, so the culprit has to be the software...

mraleph 6y ago

> 2. Dart has optional typing, which is to say it supports type hints but is essentially dynamically rather than statically typed. Dart has not been optionally typed since Dart 2 (released in 2018).

munificent 6y ago

I work on the Dart team. > 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.

dathinab 6y ago

Embedded devices which have a UI are by now normally so fast that garbage-collection doesn't matter at all. Similar you tend to not need to turn the GC at all for writing UI applications like that, the defaults are just good enough. Lastly while dart can be dynamically typed (EDIT: it's opt-in dynamic typing instead of opt-in static typing) it's typed statically "good enough". I love static typing (e.g. rust, scala) but in difference to type script I haven't run into any major gotchas when using dart. It feels very Java-ish just without the bad parts of java tbh.

1ark 6y ago

I would have thought embedded generally meant a bit more streamlined than running Dart as well. Something like https://lvgl.io https://lvgl.io (which I just heard about yesterday, thanks HN!)