Re:Rust and the Future of Systems Programming [video]
by takeda on Wednesday November 16, 2016 @02:22PM
(#12970454)
Lack of extra RAM and power to run GC is not the problem. The problem is that GC makes code behavior not predictable.
[ Parent
| on HN ]
Re:Rust and the Future of Systems Programming [video]
by pron on Wednesday November 16, 2016 @02:32PM
(#12970571)
That's not true in general. I've used realtime Java in a safety critical hard realtime application (running on a large server), with strong deadline guarantees (we're talking microsecond range). If you have the power and RAM to spare, the predictability issue is more cheaply solved with the approach I mentioned above (by cheaply I mean in terms of development costs; it is more costly than "plain" GC in terms of effort, but still cheaper than the Rust approach).
The only real cost of GC these days is RAM (and power).
Re:Rust and the Future of Systems Programming [video]
by nickpsecurity on Wednesday November 16, 2016 @04:46PM
(#12971874)
Which VM did you use for that out of curiosity?
Re:Rust and the Future of Systems Programming [video]
by pron on Thursday November 17, 2016 @01:24AM
(#12974884)
Sun's Java Real-Time System. It is no longer supported, AFAIK, and I don't know which RT JVM the project has switched to because I'm no longer there (my guess would be IBM's).
Re:Rust and the Future of Systems Programming [video]
by nickpsecurity on Wednesday November 16, 2016 @04:45PM
(#12971870)
Real-time GC's exist. Look up Aonix's Java stuff for what embedded or predictable apps do. Or JamaicaVM below. For enterprise, Azul has some amazing GC tech plus Java CPU's (Vega's).
Re:Rust and the Future of Systems Programming [video]
by Matthias247 on Wednesday November 16, 2016 @04:49PM
(#12971906)
However that's not something that is automatically solved by manual memory management. Using malloc/free on a desktop OS does also not provide a predictable runtime behavior, although unexpected pauses might be smaller than with most GCs.
The safest bet for predictable memory management and latency is the approach that is used by lots of embedded and realtime software: Don't allocate at all. Or at least don't do it in critical phases.
Re:Rust and the Future of Systems Programming [video]
by dbaupp on Wednesday November 16, 2016 @05:43PM
(#12972297)
I think this is the point that is obscured when discussing "manual memory management" vs "GC" languages and just focusing on the behaviour/life-cycle of an individual allocation: the former generally provide tools and features that make easier/more natural to avoid allocations, whereas the latter makes the assumption that allocation is usually OK (which is, of course, a perfectly acceptable trade-off for the domains those languages target).