4 ms·

Also, avoiding GC pauses while still being subject to interrupts and context switches is a common kind of tunnel vision. Non-GC languages are great for systems

Also, avoiding GC pauses while still being subject to interrupts and context switches is a common kind of tunnel vision. Non-GC languages are great for systems programming, but if GC wasn't going to be your biggest source of jitter anyway then using one just means more work and/or more bugs.

notacoward 5y ago
...not using one...
ncmncm 5y ago
This is why those of us who make low-latency systems turn off interrupts and context switches. Not using a GC does not, in fact, make more work or more bugs, given a language that provides resource management facilities, such as C++ and Rust. Programs using GC do typically leak, and most GCs make leaks much harder to find and fix. Most GCs even make it hard to determine if you have a leak.
- notacoward 5y ago
  I know you think you're a perfect programmer, but the fact is that most programmers aren't. Of the hundreds, possibly thousands, I've worked with, maybe one in twenty could be counted on to write non-trivial code without introducing new object-lifetime issues that every programmer on that project for ever after would have to keep in mind when interacting with that component. Yes, that includes quite a bit of C++ with RAII etc. but also with threads, callbacks, and ill-fated attempts to avoid copies by using references and move semantics. (C++ RAII is a hack BTW, less a resource management facility than a primitive you can use to build one, always with the sad side effect of forcing programmers to wrap their cleanup code in classes even when it's an ill fit conceptually.) So yes, in practice in real-life teams, manual memory management does lead to more work and more bugs. Only somebody who has never seriously tried to use more than a small fashionable subset of languages could claim otherwise, or that they're not using memory management at all when in fact that's only true for toy programs.
  - ncmncm 5y ago
    I am ready to believe that you, personally, introduce numerous bugs in code you write, and then blame them on averyone else and on everything but your own bad habits. But that experience does not generalize. Am I spectacularly lucky in my generally competent colleagues? I doubt it.
    - pjmlp 5y ago
      Well, apparently you are indeed. https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76D... https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/ https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s... https://support.apple.com/en-us/HT212805 https://support.apple.com/en-us/HT212805 https://support.apple.com/en-us/HT212622 https://support.apple.com/en-us/HT212622 https://support.apple.com/en-us/HT212531 https://support.apple.com/en-us/HT212531 But maybe Apple, Google and Microsoft just aren't able to hire the right kind of highly skilled C++ devs that would write such perfect code, despite having a seat at ISO, and being clang/LLVM contributors.
      - ncmncm 5y ago
        Apple, Google, and Microsoft all employ very many competent programmers. But they share the problem that they need to hire many more programmers than are both competent and eager to work for them, and so must make do for the rest. It is a much easier task to select a place to work with competent colleagues. Thus, there is no inconsistency. Perfection is not needed. Ordinary good code suffices. Good code using modern C++, or current Rust, is easier than in older languages (among which count older C++). When bad code is extra work, it becomes an unattractive alternative even to the lazy, leaving its production mainly to the masochistic and the aggressively incompetent, who are often the same.
        pjmlp 5y ago
        So the ideal programmer matra that C folks keep stating that has unfortunely taited the C++ community, despite the facts of security exploits and no such people actually existing for the last 40 years. Here is the thing, when the ISO C++ leaders, and major C++ contributors, push for a change, it is time to start doing some self reflection.

notacoward 5y ago

...not using one...

ncmncm 5y ago

This is why those of us who make low-latency systems turn off interrupts and context switches. Not using a GC does not, in fact, make more work or more bugs, given a language that provides resource management facilities, such as C++ and Rust. Programs using GC do typically leak, and most GCs make leaks much harder to find and fix. Most GCs even make it hard to determine if you have a leak.

notacoward 5y ago
I know you think you're a perfect programmer, but the fact is that most programmers aren't. Of the hundreds, possibly thousands, I've worked with, maybe one in twenty could be counted on to write non-trivial code without introducing new object-lifetime issues that every programmer on that project for ever after would have to keep in mind when interacting with that component. Yes, that includes quite a bit of C++ with RAII etc. but also with threads, callbacks, and ill-fated attempts to avoid copies by using references and move semantics. (C++ RAII is a hack BTW, less a resource management facility than a primitive you can use to build one, always with the sad side effect of forcing programmers to wrap their cleanup code in classes even when it's an ill fit conceptually.) So yes, in practice in real-life teams, manual memory management does lead to more work and more bugs. Only somebody who has never seriously tried to use more than a small fashionable subset of languages could claim otherwise, or that they're not using memory management at all when in fact that's only true for toy programs.
- ncmncm 5y ago
  I am ready to believe that you, personally, introduce numerous bugs in code you write, and then blame them on averyone else and on everything but your own bad habits. But that experience does not generalize. Am I spectacularly lucky in my generally competent colleagues? I doubt it.
  - pjmlp 5y ago
    Well, apparently you are indeed. https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76D... https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/ https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s... https://support.apple.com/en-us/HT212805 https://support.apple.com/en-us/HT212805 https://support.apple.com/en-us/HT212622 https://support.apple.com/en-us/HT212622 https://support.apple.com/en-us/HT212531 https://support.apple.com/en-us/HT212531 But maybe Apple, Google and Microsoft just aren't able to hire the right kind of highly skilled C++ devs that would write such perfect code, despite having a seat at ISO, and being clang/LLVM contributors.
    - ncmncm 5y ago
      Apple, Google, and Microsoft all employ very many competent programmers. But they share the problem that they need to hire many more programmers than are both competent and eager to work for them, and so must make do for the rest. It is a much easier task to select a place to work with competent colleagues. Thus, there is no inconsistency. Perfection is not needed. Ordinary good code suffices. Good code using modern C++, or current Rust, is easier than in older languages (among which count older C++). When bad code is extra work, it becomes an unattractive alternative even to the lazy, leaving its production mainly to the masochistic and the aggressively incompetent, who are often the same.
      - pjmlp 5y ago
        So the ideal programmer matra that C folks keep stating that has unfortunely taited the C++ community, despite the facts of security exploits and no such people actually existing for the last 40 years. Here is the thing, when the ISO C++ leaders, and major C++ contributors, push for a change, it is time to start doing some self reflection.