5 ms·

I don't really understand why people would want a GC over deterministic destruction like in Rust. GC is [neither necessary nor sufficient](https://ruudvanasseld

by dpc_pw 7y ago

I don't really understand why people would want a GC over deterministic destruction like in Rust. GC is [neither necessary nor sufficient](https://ruudvanasseldonk.com/2015/10/06/neither-necessary-nor-sufficient https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no...). Ownership model in practice is much more convenient precisely because objects can act like resources and implement their cleanup logic, and the business logic can rely on it. It's a great improvement in any imperative PL. I have (re-)implemented couple of real-life projects, and each time Rust was much better higher-level language than eg. Java, Python or JS. Borrow checker fights are non-issue in practice: just avoid references, pass messages as copies and when you have to share data use `Arc` and copy on write (or just add `Mutex`). There's a reason why Rust is most loved PL for 4 years in a row. Once you try it, and get past initial adjustments (mosty: what owns what relationship) everything clicks, and I guarantee that you won't miss GC at all.

njepa 7y ago
I think mainly because mastering new concepts increases the barrier to entry, overhead and scope. Which in turn affects creativity. There are many brilliant programming languages, used by brilliant programmers, yet, most really useful software tends to be produced by whatever. It would be awesome if Rust could overcome that, but I don't really see how currently.
- wyatwerp 7y ago
  In the no-GC no-runtime niche, you probably need brilliant programmers anyway. Most of them are banging their heads against the C++ wall right now; they would love to get back some of their lost creativity via mastering of new concepts (Rust borrow checker, or Pony's deny capabilities - https://pony-lang.io https://pony-lang.io ).
  - njepa 7y ago
    In my experience C++ programmers aren't necessarily great programmers as such. Because low levels things usually requires domain knowledge and experience more so than programming brilliance.
    - wyatwerp 7y ago
      The topic was the no-GC no-runtime niche, which necessarily requires brilliant programmers, and they are stuck with C++. They would welcome tools to represent their resource control well, borrow checking or deny capabilities. As a current C++ programmer who remembers what GCC 2.95's error messages looked like for even simple templates, I second you - it is less about the intellect, and more about experience and enough domain knowledge. But quite a few like me work on large C++ software that is not in the no-GC no-runtime niche; modules, good abstractions and native compilation would be enough to match or likely beat whatever we are putting together in C++, which doesn't even have modules yet - and the GC-based conveniences would be a big icing on the cake, so D, Nim, Pony all look interesting. (side note ... https://ponylang.io https://ponylang.io and not https://pony-lang.io https://pony-lang.io as stated earlier)
      - njepa 7y ago
        I definitely think it is needed. I just don't think Rust has solved the paradox that the more you need something specialized the less you can afford the overhead. Finding hundreds of web developers with some spare time who don't mind learning Rust, can port some of their tooling and use it in some part of their stack isn't going to be much of a problem. The same isn't true if you, say, need an embedded programmer who has worked with zigbee and needs to be in your lab for testing and verification. Pretty much all major programming languages are where they are as a result of being some kind of "lowest common denominator" for their application. Something like Bash is pretty horrible as a programming language, but extremely accessible for sysadmins. Only now is it changing slightly were things like Python and Go is becoming more popular, but mostly because they are easier than the alternatives.
pjmlp 7y ago
Because having a GC doesn't mean throwing away deterministic destruction. Many GC enabled system languages do offer both mechanisms. It is a matter of enjoying productivity it offers, while having the tools to fine tune performance when it actually matters.
- dpc_pw 7y ago
  > Many GC enabled system languages do offer both mechanisms. ? Can you give me an example? Java's `finalize` is not deterministic destruction. D's scope guards (or Go's `defer`) are also not like destructors, because a calling code has to take care of them. > It is a matter of enjoying productivity it offers, There's hardly any productivity gain, and it is being offset by productivity gained by a reliable and hassle-free resource management.
  - deleted 7y ago
    [deleted]
  - manwe150 7y ago
    Not exactly a systems language, but Python has deterministic destruction (due to the use of reference counting) of non-cyclic data structures. Edit: Oh, and if you don’t think that’s enough, note that Rust doesn’t guarantee destruction to ever occur in that case (“considered safe”): https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
    - dpc_pw 7y ago
      Oh, interesting. But from what I read it's only an implementation detail of CPython? With `with`I can't eg. pass an open file to another function to eg. be closed there etc. Example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=660bf12eee1338d4b05f747b2ba99ed6 https://play.rust-lang.org/?version=stable&mode=debug&editio... closing `File` will happen at the end of `foo` or `foo2`.
      - 7y ago
wyatwerp 7y ago
As pjmlp said below, GC doesn't preclude deterministic destruction, so it isn't about resources in general; it is largely about memory. Also typical programs in any language have quite a bit of stack-allocatable data and C/C++/D/Go/Rust do support stack-allocatation, so the memory heap isn't involved everywhere. Wherever the memory heap is involved, if the system isn't memory-starved, it can be argued that deterministic free-ing is a step too far; maybe you don't want time to be spent putting that long-ish list of heap-allocated values on the free list when exiting a function on the critical path. There is something to be said for lazy operations in such contexts, which the GC can provide (off the critical path - using GC.disable() in D) - a lot easier than a "region-based" memory management solution in C/C++/Rust. I don't know of a synthetic benchmark result to tilt the argument either way. At a system level, it is slightly dismaying that the "back-pressure" required to trigger lazy operations is only present for memory, and only within a Unix process; when it comes to limits on open file handles or sockets or overall OS memory usage, there is no back-pressure to reclaim them - indeed no mechanism to lazily schedule files/sockets for closure.
- dpc_pw 7y ago
  > indeed no mechanism to lazily schedule files/sockets for closure. It's not only about file sockets. It's about your core abstractions. Thread-pools, channels, flushing streams, events and other stuff, unlocking Mutexes, auto-validating guards etc... I have production or semi-production experience with code written in C, D, C++, Python, Go, Java, Node, Scala, Rust and others (please excuse argument from authority, but that's all I have right now) so I can tell the difference and I think ... ... people that haven't worked with Rust long enough greatly under-appreciate number of stuff that benefit from deterministic resource-like management - not only on system resource usage / performance side, but simply the day to day reliability and writing simple bug-free code with ease.
  - wyatwerp 7y ago
    I wasn't talking about necessarily temporal operations like mutex ops; of course, they should be deterministically done - it is a beautiful implementation detail that it falls out of the principles of Rust, without explicit compiler support and/or "checked-delete" as is required in most other languages. I meant lazy operations for avoiding unnecessarily making things like memory deallocation temporal. Unless you have a strict memory budget (and you might additionally need to have mitigation for memory fragmentation), freeing whenever GC deems it fit, or streams flushing whenever the OS/library deems it fit, can't be worse - but could potentially be better - for performance than being done only at points decided arbitrarily by the language and the program structure. It is simply easier to disable GC on critical paths. But as you say, you are not (only) talking about performance. You are talking about determinism for predictability. I hope you are not implying predictability across various threads/processes that make up the system, only within 1 thread/process where that predictability leads to reliability. Reliability across threads/processes needs strategy because failures are inevitable (yes, I have drunk the Erlang kool-aid too, among other ones). While I have no doubt that Rust's design principles would support developing such strategies, I do wonder as to what scale this would work up to ... ... as you say, I don't know the size of projects Rust has scaled to, I just know enough about Rust itself to balk at its complexity (and I am a C++ person!). Maybe we are just talking from different viewpoints. You, having done a variety of non-trivial production code in a plethora of languages, plump for Rust. But I honestly wonder about the size & longevity of your C/C++ semi-production code - semi, because it is C/C++ ;-) - I have worked on large C++ codebases for long-lived products, and I somehow can't see another complex language solving more problems net-net.

by dpc_pw 7y ago

njepa 7y ago

I think mainly because mastering new concepts increases the barrier to entry, overhead and scope. Which in turn affects creativity. There are many brilliant programming languages, used by brilliant programmers, yet, most really useful software tends to be produced by whatever. It would be awesome if Rust could overcome that, but I don't really see how currently.

wyatwerp 7y ago
In the no-GC no-runtime niche, you probably need brilliant programmers anyway. Most of them are banging their heads against the C++ wall right now; they would love to get back some of their lost creativity via mastering of new concepts (Rust borrow checker, or Pony's deny capabilities - https://pony-lang.io https://pony-lang.io ).
- njepa 7y ago
  In my experience C++ programmers aren't necessarily great programmers as such. Because low levels things usually requires domain knowledge and experience more so than programming brilliance.
  - wyatwerp 7y ago
    The topic was the no-GC no-runtime niche, which necessarily requires brilliant programmers, and they are stuck with C++. They would welcome tools to represent their resource control well, borrow checking or deny capabilities. As a current C++ programmer who remembers what GCC 2.95's error messages looked like for even simple templates, I second you - it is less about the intellect, and more about experience and enough domain knowledge. But quite a few like me work on large C++ software that is not in the no-GC no-runtime niche; modules, good abstractions and native compilation would be enough to match or likely beat whatever we are putting together in C++, which doesn't even have modules yet - and the GC-based conveniences would be a big icing on the cake, so D, Nim, Pony all look interesting. (side note ... https://ponylang.io https://ponylang.io and not https://pony-lang.io https://pony-lang.io as stated earlier)
    - njepa 7y ago
      I definitely think it is needed. I just don't think Rust has solved the paradox that the more you need something specialized the less you can afford the overhead. Finding hundreds of web developers with some spare time who don't mind learning Rust, can port some of their tooling and use it in some part of their stack isn't going to be much of a problem. The same isn't true if you, say, need an embedded programmer who has worked with zigbee and needs to be in your lab for testing and verification. Pretty much all major programming languages are where they are as a result of being some kind of "lowest common denominator" for their application. Something like Bash is pretty horrible as a programming language, but extremely accessible for sysadmins. Only now is it changing slightly were things like Python and Go is becoming more popular, but mostly because they are easier than the alternatives.

pjmlp 7y ago

Because having a GC doesn't mean throwing away deterministic destruction. Many GC enabled system languages do offer both mechanisms. It is a matter of enjoying productivity it offers, while having the tools to fine tune performance when it actually matters.

dpc_pw 7y ago
> Many GC enabled system languages do offer both mechanisms. ? Can you give me an example? Java's `finalize` is not deterministic destruction. D's scope guards (or Go's `defer`) are also not like destructors, because a calling code has to take care of them. > It is a matter of enjoying productivity it offers, There's hardly any productivity gain, and it is being offset by productivity gained by a reliable and hassle-free resource management.
- deleted 7y ago
  [deleted]
- manwe150 7y ago
  Not exactly a systems language, but Python has deterministic destruction (due to the use of reference counting) of non-cyclic data structures. Edit: Oh, and if you don’t think that’s enough, note that Rust doesn’t guarantee destruction to ever occur in that case (“considered safe”): https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
  - dpc_pw 7y ago
    Oh, interesting. But from what I read it's only an implementation detail of CPython? With `with`I can't eg. pass an open file to another function to eg. be closed there etc. Example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=660bf12eee1338d4b05f747b2ba99ed6 https://play.rust-lang.org/?version=stable&mode=debug&editio... closing `File` will happen at the end of `foo` or `foo2`.
    - 7y ago

wyatwerp 7y ago

As pjmlp said below, GC doesn't preclude deterministic destruction, so it isn't about resources in general; it is largely about memory. Also typical programs in any language have quite a bit of stack-allocatable data and C/C++/D/Go/Rust do support stack-allocatation, so the memory heap isn't involved everywhere. Wherever the memory heap is involved, if the system isn't memory-starved, it can be argued that deterministic free-ing is a step too far; maybe you don't want time to be spent putting that long-ish list of heap-allocated values on the free list when exiting a function on the critical path. There is something to be said for lazy operations in such contexts, which the GC can provide (off the critical path - using GC.disable() in D) - a lot easier than a "region-based" memory management solution in C/C++/Rust. I don't know of a synthetic benchmark result to tilt the argument either way. At a system level, it is slightly dismaying that the "back-pressure" required to trigger lazy operations is only present for memory, and only within a Unix process; when it comes to limits on open file handles or sockets or overall OS memory usage, there is no back-pressure to reclaim them - indeed no mechanism to lazily schedule files/sockets for closure.

dpc_pw 7y ago
> indeed no mechanism to lazily schedule files/sockets for closure. It's not only about file sockets. It's about your core abstractions. Thread-pools, channels, flushing streams, events and other stuff, unlocking Mutexes, auto-validating guards etc... I have production or semi-production experience with code written in C, D, C++, Python, Go, Java, Node, Scala, Rust and others (please excuse argument from authority, but that's all I have right now) so I can tell the difference and I think ... ... people that haven't worked with Rust long enough greatly under-appreciate number of stuff that benefit from deterministic resource-like management - not only on system resource usage / performance side, but simply the day to day reliability and writing simple bug-free code with ease.
- wyatwerp 7y ago
  I wasn't talking about necessarily temporal operations like mutex ops; of course, they should be deterministically done - it is a beautiful implementation detail that it falls out of the principles of Rust, without explicit compiler support and/or "checked-delete" as is required in most other languages. I meant lazy operations for avoiding unnecessarily making things like memory deallocation temporal. Unless you have a strict memory budget (and you might additionally need to have mitigation for memory fragmentation), freeing whenever GC deems it fit, or streams flushing whenever the OS/library deems it fit, can't be worse - but could potentially be better - for performance than being done only at points decided arbitrarily by the language and the program structure. It is simply easier to disable GC on critical paths. But as you say, you are not (only) talking about performance. You are talking about determinism for predictability. I hope you are not implying predictability across various threads/processes that make up the system, only within 1 thread/process where that predictability leads to reliability. Reliability across threads/processes needs strategy because failures are inevitable (yes, I have drunk the Erlang kool-aid too, among other ones). While I have no doubt that Rust's design principles would support developing such strategies, I do wonder as to what scale this would work up to ... ... as you say, I don't know the size of projects Rust has scaled to, I just know enough about Rust itself to balk at its complexity (and I am a C++ person!). Maybe we are just talking from different viewpoints. You, having done a variety of non-trivial production code in a plethora of languages, plump for Rust. But I honestly wonder about the size & longevity of your C/C++ semi-production code - semi, because it is C/C++ ;-) - I have worked on large C++ codebases for long-lived products, and I somehow can't see another complex language solving more problems net-net.