There's a market for embedded Java. Atego makes a variety of runtimes for real-time use.

http://www.ptc.com/developer-tools/perc

Latency under 1ms per their material.

That's interesting, from a business perspective. How did they arrive at that market via CAD?

What do you mean arrive "via CAD?" What is CAD in this context?

I mean how did PTC go from selling solid modelling software for IRIX to hawking an embedded JVM?

Hell, I didn't even know they were PTC now. On an acquisition or name-changing spree it seems lol. Aonix developed and marketed the Java technology. Got acquired by Atego and now apparently PTC. You will probably find the Wayback Machine's copy more informative with the non-JS links on left leading to PDF's showing its capabilities:

https://web.archive.org/web/20111101211755/http://www.aonix....

They had standard Java support, a better native API, GC pauses down to 100 microseconds, AOT compilation, and so on. I especially liked how they supported separation kernels like INTEGRITY and non-x86 architectures. The ability to use strong, user-mode isolation on the VM plus obfuscation of codebase and processor ISA makes for high resistance to whatever Internet throws at you. ;) Plus, embedded boards can be really cheap w/ Freescale's doing I/O, crypto, and TCP acceleration.

So, I thought it was cool shit that could've benefited mainstream market if they thought of things like this and applied it properly. Could always build, in parallel, a FOSS-based setup in case they pulled out or some other crap that happens with proprietary companies. Can just painlessly move off their stack. Meanwhile, their stack rocked in its domain, still does given numbers I'm seeing in Go etc, and it's worth copying in some ways.

Yes, very much so. GC on powerful servers is a well trodden path. Low power devices much less so.

Isn't it a less troden path because it's sacrificing too much and gaining too little, especially when we have languages coming up like rust with the memory safety of a GC but no gc runtime cost?

I ask because I don't have much low-level/embedded experience, and I'm unaware of why you'd want a gc on such low power systems. If there's a use case though, I'd love to learn about it!

I think the question is easier to answer if we view "garbage collection" as automatic memory management in general, rather than a more specific case of automatic memory management via a runtime task colloquially known as the garbage collector. I believe automatic memory management is a universally desirable property whether you are running on a server or a small device. However, since you brought up Rust, I also think it is valid to debate the value of a runtime GC as opposed to another automatic memory management technique like automatic reference counting. I don't think that question is embedded-specific though: it applies just as much to the server environment.

How is tracing GC vs. pervasive reference counting relevant to Rust?

I merely used automatic reference counting as one alternative automatic memory management technique. Rust, as I understand it, uses a similar alternative, which is, at least on paper, similar to enforcing a max refcount of one on pointers, statically. I'm far from a Rust expert so feel free to correct me if I'm wrong.

I'd say that "reference counting" implies a dynamic/runtime component, which is not how Rust manages memory (unless you're specifically using the `Rc` pointer in the stdlib).

I think it's important to be clear here because Swift and Objective-C rely on a technology known as "Automatic Reference Counting" (ARC), which does imply the usual dynamic cost of reference counting.