6 ms·

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+

by 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.

kaba0 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. Well, yes and no. Sure, it helps with data races (but not with race conditions in general), but foremost it is a tool that allows for correct compile-time memory management. Compile-time memory management is only possible in a subset of programs, so rust as well has to use (A)RC at times. This is okay when used sparingly, but atomic increases are very expensive on today’s hardware. I am familiar with RAII, but that is the exact same thing what Rust enforces at compile time, with the exact same shortcomings, so I don’t see how is it an argument against GC. Reference counting can cause long pauses as well - as I said, it is the same problem, just looking at it from the other direction. If an object with many many references to plenty other objects die it can take quite a long time to deallocate, there are no free lunch. And then we haven’t even talked about cycles that need a similar background process to tracing GCs, without which it will leak. Also, I have seen the interview, I believe this thread is about it: https://news.ycombinator.com/item?id=31139610 https://news.ycombinator.com/item?id=31139610 While I am all for research into better ways to do RC, please look at the discussion - it is not at all clear that RC would be better, and even theoretically a tracing GC will win.
- tjoff 4y ago
  Yes and yes. Why on earth would "doesn't solve X" be an argument against that it does Z + Y ? Whereas a GC only does Z. It was an alternative, that does less and doesn't put as much restrictions on the programmer compared to the borrow checker, as you complained about rust and equaled that with not having a GC. And it is deterministic. >While I am all for research into better ways to do RC, please look at the discussion - it is not at all clear that RC would be better, and even theoretically a tracing GC will win. Win what and in what sense? How every GC language has problems with GC tuning is in my opinion a clear indicator that the GC lost. With no real benefits short term and huge downsides down the line - even if you never hit any limits.
  - kaba0 4y ago
    The borrow checker doesn’t give a complete answer to memory management, as dynamic allocation patterns by definition can’t be done at compile time unless you can solve the halting problem. > How every GC language has problems with GC tuning is in my opinion a clear indicator that the GC lost. Citation required. It Just Works in like 99% of cases, and it’s not like there is any solution that covers every edge case. Just look at the thread I linked, there is an example of C++’s RC lingering for a long time after the effective work is done freeing many things.
    - tjoff 4y ago
      Did I say it did? The operations are deterministic but dynamic memory is not. But that alone is quite important. Lucky for the non-GC crowd though, as the languages often give you a stronger control over what is allocated on the stack and not. It is an axiom at this point. GC battles are not exactly unheard of on HN. Don't worry, it gets fixed in the upcoming release - has been said for decade after decade. No there is no solution that covers any case. But you pretty much always have to think about memory, so the appeal of using a GC when the only argument in its favor is that you don't have to think about memory is quite unclear.

by tjoff 4y ago

kaba0 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. Well, yes and no. Sure, it helps with data races (but not with race conditions in general), but foremost it is a tool that allows for correct compile-time memory management. Compile-time memory management is only possible in a subset of programs, so rust as well has to use (A)RC at times. This is okay when used sparingly, but atomic increases are very expensive on today’s hardware. I am familiar with RAII, but that is the exact same thing what Rust enforces at compile time, with the exact same shortcomings, so I don’t see how is it an argument against GC. Reference counting can cause long pauses as well - as I said, it is the same problem, just looking at it from the other direction. If an object with many many references to plenty other objects die it can take quite a long time to deallocate, there are no free lunch. And then we haven’t even talked about cycles that need a similar background process to tracing GCs, without which it will leak. Also, I have seen the interview, I believe this thread is about it: https://news.ycombinator.com/item?id=31139610 https://news.ycombinator.com/item?id=31139610 While I am all for research into better ways to do RC, please look at the discussion - it is not at all clear that RC would be better, and even theoretically a tracing GC will win.

tjoff 4y ago
Yes and yes. Why on earth would "doesn't solve X" be an argument against that it does Z + Y ? Whereas a GC only does Z. It was an alternative, that does less and doesn't put as much restrictions on the programmer compared to the borrow checker, as you complained about rust and equaled that with not having a GC. And it is deterministic. >While I am all for research into better ways to do RC, please look at the discussion - it is not at all clear that RC would be better, and even theoretically a tracing GC will win. Win what and in what sense? How every GC language has problems with GC tuning is in my opinion a clear indicator that the GC lost. With no real benefits short term and huge downsides down the line - even if you never hit any limits.
- kaba0 4y ago
  The borrow checker doesn’t give a complete answer to memory management, as dynamic allocation patterns by definition can’t be done at compile time unless you can solve the halting problem. > How every GC language has problems with GC tuning is in my opinion a clear indicator that the GC lost. Citation required. It Just Works in like 99% of cases, and it’s not like there is any solution that covers every edge case. Just look at the thread I linked, there is an example of C++’s RC lingering for a long time after the effective work is done freeing many things.
  - tjoff 4y ago
    Did I say it did? The operations are deterministic but dynamic memory is not. But that alone is quite important. Lucky for the non-GC crowd though, as the languages often give you a stronger control over what is allocated on the stack and not. It is an axiom at this point. GC battles are not exactly unheard of on HN. Don't worry, it gets fixed in the upcoming release - has been said for decade after decade. No there is no solution that covers any case. But you pretty much always have to think about memory, so the appeal of using a GC when the only argument in its favor is that you don't have to think about memory is quite unclear.