4 ms·

I can write (and am in fact developing right now) a music app in a non-GC language, with a real-time audio thread which (unless faced with unusual inputs like h

I can write (and am in fact developing right now) a music app in a non-GC language, with a real-time audio thread which (unless faced with unusual inputs like hundreds of simultaneous events) performs zero allocations or deallocations after initial startup. It acquires and releases all heap allocations from a wait-free queue between the audio thread and GUI thread. If I were to port the app to C#, I have no way of telling the C# GC to never pause the audio thread, and to only pause the GUI thread. I'm not sure if it's possible for a tracing GC to coexist with a never-paused thread which owns manually memory-managed types, and for the two threads to exchange manually freed or GC'd objects without FFI boilerplate, serialization, or copying. If it exists (and there's a GUI framework written in the GC portion of the language), let me know! Admittedly manual memory management does mean a lot more things to worry about (ranging from manual memory management to lock-free wait-free programming) Personally I find deterministic lifetimes and single ownership which can be moved/swapped to be elegant. However, Qt's QObject system combines the practical disadvantages of manual freeing (having to track complex semantics in your head, and check whether each method call transfers ownership or not, with leaks or use-after-free if you get it wrong) with the inelegance of GC (pervasive aliasing and mutability, unclear ownership, a magical runtime-like system).

Skinney 5y ago
Sure, and in your specific use case, the tradeoff of dealing with memory seems worth it. My point was that there are tradeoffs, which you admit. The comment i responded to indicated that there wasn’t one.
kaba0 5y ago
I agree that your specific use-case is indeed good reason for manually managed memory, but theoretically, I don’t see anything inherent in specifying GC on a per-thread basis. Like, perhaps one could set a property on a new Thread object and set GC to false - that would probably allow your program to function even in a managed environment.
- ncmncm 5y ago
  Not using GC does not, in fact, imply "manually managed memory". Manually managed memory is the only thing possible in C, but C is not the only non-GC language. The most commonly used non-GC languages provide other mechanisms, and usual practice in them is to rely on their non-GC, automated memory management.
  - kaba0 5y ago
    Do you mean RAII and rust’s ownership model? It still has very similar tradeoffs to manual memory management, they are just much less error prone. But the fundamental thing is that you still have to think about memory, memory layout will have to be considered during refactors, etc.
    - ncmncm 5y ago
      If you are not thinking about memory, or memory layout, you are not programming. Anyway, not programming well. And "tradeoffs" is a misleading term to apply to a process that does not involve giving up anything in exchange for the benefit of pause-free, fully predictable operation.
      - kaba0 5y ago
        There are different levels of “thinking about memory”. The distinction between low and high level languages is not arbitrary. In a CRUD app, you don’t want memory layout to be the center of attention, a major refactor in abstraction should not really require a re-thought on the life time of objects, etc. And you do absolutely give up something with not using a GC: speed of development, much bigger teams can work on the project at the same time while not stepping as much on each other’s foot, etc. It’s not an accident that perhaps the majority of all software development is in managed languages, where it is not absolutely crucial to control the exact memory layout.
        ncmncm 5y ago
        > "you do absolutely give up ... speed of development" That is the advertising claim, not substantiated. A more plausible explanation for "the majority ... in managed languages" is: it enables employing lower-skilled, thus more easily obtained, labor. It doesn't so much matter how fast development is. Such practices commonly split a simple job among five or more people (a "team") who, collectively, probably cost more than one more-skilled employee who could do it all in much less time, but who is hard to attract to do it at all, and anyway better used elsewhere.

Skinney 5y ago

Sure, and in your specific use case, the tradeoff of dealing with memory seems worth it. My point was that there are tradeoffs, which you admit. The comment i responded to indicated that there wasn’t one.

kaba0 5y ago

I agree that your specific use-case is indeed good reason for manually managed memory, but theoretically, I don’t see anything inherent in specifying GC on a per-thread basis. Like, perhaps one could set a property on a new Thread object and set GC to false - that would probably allow your program to function even in a managed environment.

ncmncm 5y ago
Not using GC does not, in fact, imply "manually managed memory". Manually managed memory is the only thing possible in C, but C is not the only non-GC language. The most commonly used non-GC languages provide other mechanisms, and usual practice in them is to rely on their non-GC, automated memory management.
- kaba0 5y ago
  Do you mean RAII and rust’s ownership model? It still has very similar tradeoffs to manual memory management, they are just much less error prone. But the fundamental thing is that you still have to think about memory, memory layout will have to be considered during refactors, etc.
  - ncmncm 5y ago
    If you are not thinking about memory, or memory layout, you are not programming. Anyway, not programming well. And "tradeoffs" is a misleading term to apply to a process that does not involve giving up anything in exchange for the benefit of pause-free, fully predictable operation.
    - kaba0 5y ago
      There are different levels of “thinking about memory”. The distinction between low and high level languages is not arbitrary. In a CRUD app, you don’t want memory layout to be the center of attention, a major refactor in abstraction should not really require a re-thought on the life time of objects, etc. And you do absolutely give up something with not using a GC: speed of development, much bigger teams can work on the project at the same time while not stepping as much on each other’s foot, etc. It’s not an accident that perhaps the majority of all software development is in managed languages, where it is not absolutely crucial to control the exact memory layout.
      - ncmncm 5y ago
        > "you do absolutely give up ... speed of development" That is the advertising claim, not substantiated. A more plausible explanation for "the majority ... in managed languages" is: it enables employing lower-skilled, thus more easily obtained, labor. It doesn't so much matter how fast development is. Such practices commonly split a simple job among five or more people (a "team") who, collectively, probably cost more than one more-skilled employee who could do it all in much less time, but who is hard to attract to do it at all, and anyway better used elsewhere.