Hacker News Reader

Comment by s_tec | Hacker News Reader

I remember a time when people asked, "What will replace the floppy drive?" Everyone expected the replacement to look and feel like a floppy drive, but with more speed and capacity. In the end, the "floppy killer" never materialized. Several unrelated technologies ended up taking over floppy's uses one-by-one. CD-ROM's took over software distribution, USB thumb drives took over file transfer between computers, and the network took over everything else.

The same thing will probably happen to C. Modern languages like Python or have arguably "replaced C" in several use-cases already. Go will probably claim a few more. On the other hand, Go is completely unsuitable for applications that cannot tolerate garbage collection, such as embedded firmware. Some other language will have to come along and claim that niche from C as well.

View on HN

I'm not so sure there are applications which simply cannot tolerate garbage collection. Unless, you have no reasonable way of preventing allocations.

Console games, for instance, are often largely garbage collected, despite being hugely performance critical applications. The way this is generally achieved is by allocating 100% of the console's memory upfront as object pools. The game then utilizes domain specific collection mechanisms on those pools.

Shawn Hargreaves has a good article on dealing with C#'s garbage collection in XNA games: http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-pat...

The problem in .NET land is that some base class library methods allocate internally, so you need to completely avoid them if you use "Path 1" (avoid collections). You wind up having to do funky things like re-implementing core methods and pre-allocating pools of strings to avoid concatenation. Presumably, a language designed to be a systems language could avoid these library problems.

I don't know much about Go, but if allocations are clearly demarcated and easily avoidable when necessary, you could allocate 100% of memory up front. You could treat virtual memory as an object pool of memory pages and perform domain specific allocation on those.

Alternatively, a collector with a richer interface, such as generation control, multiple heaps, etc. Would allow for "Path 2" (avoid latency) by performing very small, simple collections.

>I'm not so sure there are applications which simply cannot tolerate garbage collection.

Things that need to be really seriously realtime, such as aeroplane pilot assistance AI, and medical equipment firmware, I think these cannot use stuff like GC because there is no room for the slightest deviation in performance.

As snprbob86 already mentioned, you pre-allocate all the memory you will need, so GC never runs.

> Things that need to be really seriously realtime

Real-time garbage collection (hard and soft) is not a work of fiction. Hell, the first papers on real-time GCs were in the 70s.

> I think these cannot use stuff like GC because there is no room for the slightest deviation in performance.

IBM's Metronome (Bacon & al) is a hard real-time GC.

> Things that need to be really seriously realtime, such as aeroplane pilot assistance AI, and medical equipment firmware, I think these cannot use stuff like GC because there is no room for the slightest deviation in performance.

Nope - real time systems have room for deviation. They "just" have different bounds. Specifically, hard real time "merely" requires guarantees that operations complete before their deadline.

For example, real-time systems can have caches even though they introduce varibility in execution time.

Of course, the closer one is to the edge, the less room for error or mis-allocation, aka "time fragmentation".

I've never done this kind of programming around GC, is manual memory management in a garbage collected language any better than manual memory management in a language without GC?

>I'm not so sure there are applications which simply cannot tolerate garbage collection.

From your post, it sounds like "tolerating garbage collection" is the same as making sure it never ever happens. The application clearly doesn't tolerate GC, the programmer tolerates the language enough to bend over backwards to avoid one of its central features.

There are microcontrollers with only 128 bytes of ram and 1KB of flash. They don't have enough memory to support malloc, so there is nothing to garbage collect in the first place. There isn't enough flash to even store the garbage collector's code, even if it sits unused.

For what its worth, Tim Sweeney appears to endorse GC for game programming in his POPL talk:

http://lambda-the-ultimate.org/node/1277

The difference between floppies and programming languages is that as storage technologies improved, the use-case for a floppy drive disappeared. (Although I think that CDs actually replaced floppies, but that's besides the point - they're on their way out, too.)

But as computer technology in general improves, the use-cases for C do not disappear. C is still needed where it's good. So unlike a floppy drive, a replacement programming language will have to compete with C's strengths.

The threat there is simply that embedded firmwares are now much bigger and more capable (and more likely to have room for GC) than ever before.

I think you're spot on.

ah yes, the Zip-drive. I remember those... shudder

http://en.wikipedia.org/wiki/Zip_drive

Reply on news.ycombinator.com