5 ms·

Or, you use a non-GC language for any application where you care about memory (hint, vast majority of applications fall into this category). GC is imo the sing

• verdagon 4y ago
  In a lot of fields, it's more important to have a codebase that's easier to use and more flexible than a codebase that uses less memory. This is why people opt for GC and why it's such a big benefit.
  • tjoff 4y ago
    I'm not really talking about memory requirements. And I don't see how a GC would make any difference in terms of ease of use or flexibility of a codebase. It is a mindset about memory, but you have to have a mindset about memory anyway so it isn't exactly unique.
    • worik 4y ago
      It is important to have a code base that an inexperienced programmer can work on. Keeping track of memory is one of the hardest parts of programming in languages like C, a bit easier in C++ (thanks RAII) but still memory leaks are rampant. Rust improves in some aspects, but I do not think it is a language for inexperienced programmers. So where garbage collection pauses are tolerable, and real time performance not an issue, save the money and use garbage collection. I too hate garbage collectors, I want to be in control. But the business case is clear: garbage collected languages are a better choice in a lot, f not most, cases.
      • tene 4y ago
        For most people working a career as a programmer, how much of their time in that career is going to be spent as an inexperienced beginner programmer? I agree that Rust is a professional tool, designed for professional use. It's designed for professional use, instead of being optimized for inexperienced beginners like Python is. I just don't really see "inexperienced beginners can easily contribute productively to this code base" as something that would have been valuable for any of the professional work I've done over the past couple of decades of my career. If you're an amateur, or if you're programming recreationally, or if you're writing some low-reliability low-impact throwaway code, sure, it's great to use happy-path-oriented languages. When you want to write something that people actually rely on to run a business, you should use professional-grade tools instead.
    • verdagon 4y ago
      In a language like Rust, one has to carefully orchestrate the dance between Ship, &mut Ship, and &Ship... and Rc<Ship> and RefCell<Ship> and Cell<Ship> and Rc<RefCell<Ship>> and Box<Ship>. In the kind of programming most people do, that is harder than GC which doesn't have any of those distinctions. It's all just Ship. If that isn't hard to you, it's probably because you've gotten so used to that mental overhead that you don't notice the drag any more, or because it's worth it for your case so you don't feel it. More power to you, but the rest of programmers don't want to have to deal with that, and don't need to. They'd rather get the feature done and go home to their families.
      • tjoff 4y ago
        The point is that the mental overhead with memory must always be there. Why not let the language guide you? Sure, they'll get the feature "done". And then they'll suffer for it later, adding up to much more work and a much less rewarding code base than if they'll done it properly in the first place.
  • dataangel 4y ago
    It's way more than just a memory use problem. Garbage collection trashes the CPU cache, and unless you aggressively use value types you have extra layers of indirection everywhere that trash it even more. GC languages have a deserved reputation for worse performance.
• kaba0 4y ago
  GC is the only measurable, significant productivity improvement in software development since high-level languages.
  • 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.