Given that there are real time JVMs controlling ballistic systems and aiming turrets on battleships, I guess they have a pretty good predictable response time.
Also I have a JVM running on the Cisco phone on my desk and the Ricoh laser printer down the hall.
Just, because there is a portion of the market that a certain concept doesn't apply, it doesn't mean it isn't viable in other segments of the same market.
For Go to be successful on embedded systems, doesn't mean it must run everywhere.
Heck there are even embedded CPUs that cannot cope with ANSI C, and that hasn't prevented people to make use of it on other market segments of the embedded space.
"its not about size, its about predictable response time."
Far as GC's, it's also about size if it's a constrained embedded system. I've seen a number of GC papers discussing tradeoffs between size (i.e. RAM use) vs speed/latency. This even factors in a bit on the large ones like Vega where they were still balancing those factors to get an optimal, "pauseless" GC for accelerating enterprise apps.
Embedded systems range from the tiniest microcontroller up to multi-core xeons, DSPs and FPGAs.
Embedded != small.
The typical issues associated with embedded development are 1) cost and 2) response time (for real-time embedded systems).
The big one here is cost. If you're wasting a single byte in your code, you have to pay that cost in every single unit you make (e.g. millions).