4 ms·

Only if you don't care about a decent memory architecture. And if you don't you'll have to pay for it many times over for the remainder of the products lifetim

by tjoff 4y ago

Only if you don't care about a decent memory architecture. And if you don't you'll have to pay for it many times over for the remainder of the products lifetime.

kaba0 4y ago
That’s way too dismissive, and is outright false. First of all, memory architecture is not thrown out the window with a GC, there are plenty of considerations that can be done in managed languages as well. Also, many managed languages have value types, allowing for basically every memory pattern you would use in a low-level language. Second of all, a GC is the superior way of handling many, random-allocations with no patterns. An allocation in a modern GC will literally be an integer increment (not even atomic!), and every later step will happen on another thread in parallel, not slowing down the thread doing the work. No malloc implementation can beat it (unless it doesn’t care about freeing). For the rare case where an arena allocator is a better approach, the aforementioned managed languages with value types are there.
- tjoff 4y ago
  Of course not, you can have an excellent memory architectures with a GC. My point is that if you do that, well, then you've done the hard parts of living without a GC - so might as well ditch it altogether. But the absolute vast majority of course doesn't have excellent memory architectures, so they'll suffer greatly from not being "burdened" with having to think about memory. It is unfortunate that GC debate is all about performance. The programmer ergonomics alone makes the GC a worse choice. But then of course we still have GC tuning.
  - kaba0 4y ago
    I don’t understand you completely. Most programs are not video decoders running a tiny tiny code on gigabytes of data, they contain quite a bit of code and many parts of it run irregularly. By not “paying attention” to memory allocations on these vast amount of cases, you get similar, or sometimes even better performance, safer and more correct software, faster. If it turns out to be a critical part, it is very easy to pay a bit more attention to the allocation story there. So in like 90+% of cases, a GC is a huge boost to productivity, and this is proved by their extensive usage in the industry.
    - tjoff 4y ago
      I'd liken it to the Linus quote regarding data-structures https://lwn.net/Articles/193244/ https://lwn.net/Articles/193244/ And in what world is a GC safer and more correct? And no, please don't argue that it is faster in any meaningful way. > So in like 90+% of cases, a GC is a huge boost to productivity, and this is proved by their extensive usage in the industry. It is not a boost in productivity. And the reason for why it has extensive use in the industry is because the sad state of programming languages have been that languages with GC are safe and high-level whereas languages without a GC are old and unsafe. That really has nothing to do with the GC though. Which is why I say that the GC has been the biggest mistake in software engineering. Rust and Swift are beginning to change that in a very small way.
      - kaba0 4y ago
        Rust actually solves the problem, although by taking a huge toll in the form of the borrow checker. It is a very good idea, but just see this thread, it is not applicable everywhere - which is okay. Rust is a low-level language made for low-level programs where absolute control over the execution is needed. Swift chose a different approach, but their tradeoff was lower memory overhead vs performance. It is likely a worthwhile goal for mobile devices, but that is a niche. And by the way, for all practical purposes RC is a garbage collection algorithm, it just tracks dead links instead of live ones. So there is one solution for correctness and safety without GC, which comes with plenty of warts. How exactly GC is not a boost in productivity?
        tjoff 4y ago
        The borrow checker does a whole lot more than replacing the GC though so it is very weird to point at it and say that the lack of a GC leads to that. Modern C++ works very well too, but it is of course a huge language with a lot of legacy that makes it unsuitable or undesirable for a lot of things. But again, completely orthogonal to the GC. That's a very shallow dismissal of swift... Oh, and Chris Lattner would not agree: https://atp.fm/205-chris-lattner-interview-transcript#gc https://atp.fm/205-chris-lattner-interview-transcript#gc > How exactly GC is not a boost in productivity? You claim that every other sentence but present nothing to stand on. The interview linked above shows some perspective if you care. You are not relieved from thinking about memory with a GC. GC is a sensible response to C-style memory management, but not to any form of manual memory management. The problem is that the options for non-GC languages are so poor, so the most reasonable language choice gives you a GC whether you want it or not. Hence my main point. So it's not like you pick Go because it has a GC. But you might pick Go despite it having a GC.
pjmlp 4y ago
Depends on how much attention one was paying during their data structures and algorithms lectures, and if the language also has support for value types, manual memory management and trailing lambdas or not.

by tjoff 4y ago

Only if you don't care about a decent memory architecture. And if you don't you'll have to pay for it many times over for the remainder of the products lifetime.

kaba0 4y ago

That’s way too dismissive, and is outright false. First of all, memory architecture is not thrown out the window with a GC, there are plenty of considerations that can be done in managed languages as well. Also, many managed languages have value types, allowing for basically every memory pattern you would use in a low-level language. Second of all, a GC is the superior way of handling many, random-allocations with no patterns. An allocation in a modern GC will literally be an integer increment (not even atomic!), and every later step will happen on another thread in parallel, not slowing down the thread doing the work. No malloc implementation can beat it (unless it doesn’t care about freeing). For the rare case where an arena allocator is a better approach, the aforementioned managed languages with value types are there.

tjoff 4y ago
Of course not, you can have an excellent memory architectures with a GC. My point is that if you do that, well, then you've done the hard parts of living without a GC - so might as well ditch it altogether. But the absolute vast majority of course doesn't have excellent memory architectures, so they'll suffer greatly from not being "burdened" with having to think about memory. It is unfortunate that GC debate is all about performance. The programmer ergonomics alone makes the GC a worse choice. But then of course we still have GC tuning.
- kaba0 4y ago
  I don’t understand you completely. Most programs are not video decoders running a tiny tiny code on gigabytes of data, they contain quite a bit of code and many parts of it run irregularly. By not “paying attention” to memory allocations on these vast amount of cases, you get similar, or sometimes even better performance, safer and more correct software, faster. If it turns out to be a critical part, it is very easy to pay a bit more attention to the allocation story there. So in like 90+% of cases, a GC is a huge boost to productivity, and this is proved by their extensive usage in the industry.
  - tjoff 4y ago
    I'd liken it to the Linus quote regarding data-structures https://lwn.net/Articles/193244/ https://lwn.net/Articles/193244/ And in what world is a GC safer and more correct? And no, please don't argue that it is faster in any meaningful way. > So in like 90+% of cases, a GC is a huge boost to productivity, and this is proved by their extensive usage in the industry. It is not a boost in productivity. And the reason for why it has extensive use in the industry is because the sad state of programming languages have been that languages with GC are safe and high-level whereas languages without a GC are old and unsafe. That really has nothing to do with the GC though. Which is why I say that the GC has been the biggest mistake in software engineering. Rust and Swift are beginning to change that in a very small way.
    - kaba0 4y ago
      Rust actually solves the problem, although by taking a huge toll in the form of the borrow checker. It is a very good idea, but just see this thread, it is not applicable everywhere - which is okay. Rust is a low-level language made for low-level programs where absolute control over the execution is needed. Swift chose a different approach, but their tradeoff was lower memory overhead vs performance. It is likely a worthwhile goal for mobile devices, but that is a niche. And by the way, for all practical purposes RC is a garbage collection algorithm, it just tracks dead links instead of live ones. So there is one solution for correctness and safety without GC, which comes with plenty of warts. How exactly GC is not a boost in productivity?
      - tjoff 4y ago
        The borrow checker does a whole lot more than replacing the GC though so it is very weird to point at it and say that the lack of a GC leads to that. Modern C++ works very well too, but it is of course a huge language with a lot of legacy that makes it unsuitable or undesirable for a lot of things. But again, completely orthogonal to the GC. That's a very shallow dismissal of swift... Oh, and Chris Lattner would not agree: https://atp.fm/205-chris-lattner-interview-transcript#gc https://atp.fm/205-chris-lattner-interview-transcript#gc > How exactly GC is not a boost in productivity? You claim that every other sentence but present nothing to stand on. The interview linked above shows some perspective if you care. You are not relieved from thinking about memory with a GC. GC is a sensible response to C-style memory management, but not to any form of manual memory management. The problem is that the options for non-GC languages are so poor, so the most reasonable language choice gives you a GC whether you want it or not. Hence my main point. So it's not like you pick Go because it has a GC. But you might pick Go despite it having a GC.

pjmlp 4y ago

Depends on how much attention one was paying during their data structures and algorithms lectures, and if the language also has support for value types, manual memory management and trailing lambdas or not.