6 ms·

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

by s_tec 15y ago

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.

killerswan 15y ago
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.
snprbob86 15y ago
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-paths-to-garbage-collector-nirvana.aspx 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.
- JonnieCache 15y ago
  >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.
  - lysium 15y ago
    As snprbob86 already mentioned, you pre-allocate all the memory you will need, so GC never runs.
  - masklinn 15y ago
    > 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.
  - anamax 15y ago
    > 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".
- bxr 15y ago
  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.
dschobel 15y ago
ah yes, the Zip-drive. I remember those... shudder http://en.wikipedia.org/wiki/Zip_drive http://en.wikipedia.org/wiki/Zip_drive
scott_s 15y ago
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.

by s_tec 15y ago

killerswan 15y ago

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.

snprbob86 15y ago

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-paths-to-garbage-collector-nirvana.aspx 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.

JonnieCache 15y ago
>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.
- lysium 15y ago
  As snprbob86 already mentioned, you pre-allocate all the memory you will need, so GC never runs.
- masklinn 15y ago
  > 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.
- anamax 15y ago
  > 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".
bxr 15y ago
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.

dschobel 15y ago

ah yes, the Zip-drive. I remember those... shudder http://en.wikipedia.org/wiki/Zip_drive http://en.wikipedia.org/wiki/Zip_drive

scott_s 15y ago

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.