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