3 ms·
Rust forces you to think about memory access carefully, but mostly it handles the allocation/deallocation for you. Is that what you meant?
by queuebert 5y ago
Rust forces you to think about memory access carefully, but mostly it handles the allocation/deallocation for you. Is that what you meant?
- wyager 5y agoIt only “handles allocation/deallocation for you” in the sense that the lifetime system forces you to write code that adheres to RAII. It handles a lot less than a language with a GC, for example.
- pjmlp 5y agoWhile a language with GC, can still allow for RAII and value allocations while handling lot more.
- dan-robertson 5y agoI don’t really understand what you mean. The main reason people complain about gc is performance: 1. costs to average performance from doing gc 2. Jitter/increased tail latency from collections and (particularly) compaction which one can’t easily control. I don’t believe that much in #1. Tracking memory with something like malloc can be slow and allocation with a typical gc is usually a few instructions bumping a pointer. If most of the minor heap is dead then deallocation is likely cheaper too. I think most of the differences are in programming style as when allocations are easy and cheap, programs tend to allocate a lot. #2 is still true though modern gcs can have very low pause times. And manual memory management can still lead to pauses waiting on the kernel (or in its page fault handler) for more memory. Other issues for gc languages is that one generally doesn’t get data access patterns that are performant. C/C++/Rust objects generally get included in one another rather than referenced with pointers and most short-lived allocations happen on the stack which will very likely be in the cache. If you write in a RAII style or with value allocations (note that in ocaml the only ‘value allocations’ are things that fit in a single 63 bit integer) with gc then, in a typical language, you still pay the cost of gc when you don’t use it.
- pjmlp 5y agoThe main reason people complain about gc is cargo cult about stuff they don't understand. 1. Then don't do GC, use the language features for stack allocation, native heap allocation, RAII 2. Just like most malloc()/free() implementations, where you don't control how they talk with the actual OS heap management APIs, as you mention Naturally not all GC enabled languages provide such features, so one looks at Python or Java, and thinks all GC languages were born alike. Examples of GC languages where you can do exactly the same stuff as in C/C++/Rust, Common Lisp, Oberon, Oberon-2, Component Pascal, Active Oberon, Modula-3, D, Nim, Eiffel, C#, F#, Swift. Also note that on my earlier comment I wasn't referring to OCaml in particular, rather languages of the list above, yet Cisco might be relatively happy with their MirageOS research. https://dl.acm.org/doi/abs/10.1145/3264560.3264561 https://dl.acm.org/doi/abs/10.1145/3264560.3264561 Here is a little gem of what happens when the low level coding features of GC enabled languages are taken into the hands of people that actually know how to use them. https://devblogs.microsoft.com/aspnet/grpc-performance-improvements-in-net-5/ https://devblogs.microsoft.com/aspnet/grpc-performance-impro... .NET 6 is bringing even more C++ like features into the managed world for .NET devs.
- queuebert 5y agoAn interesting point. RAII makes you do work by forcing you to think a certain way. In Rust that manifests as borrow checker struggles, which are huge productivity sinks up front, but which we all hope saves work down the road. Time will tell, I suppose.