4 ms·
All that Rust does wrt to that is to enforce reference counting overhead. That has well known issues and limitations and is not very attractive, either.
by gmueckl 7y ago
All that Rust does wrt to that is to enforce reference counting overhead. That has well known issues and limitations and is not very attractive, either.
- jhomedall 7y agoThe only types in the Rust standard library that do reference counting are `Rc` and `Arc` (which are both implemented in Rust). Borrow checking is done statically.
- gmueckl 7y agoBut borrow checking doesn't cover heap allocations.
- jcranmer 7y agoYes it does. Borrow guarantees that the lifetime of the borrower does not exceed the lifetime can provide. Heap allocations have a lifetime--the start of a Box<> is the call to malloc, and the end is the call to free. Borrow checking prevents you from using the value after the free.
- geofft 7y agoHuh? It absolutely does, you can store a Box<T> somewhere and get multiple &'a Ts out of it, where 'a is limited to the lifetime of the box, but only one &'a mut T out of it at once.
- gmueckl 7y agoNo, this does not mean that the borrow checker understands heap allocations. Box is just a wrapper to shoehorn heap management into the stack based analysis that the borrow checker is able to perform. In other words, Box<> is just the equivalent of std::unique_ptr in C++.
- dthul 7y agoI see what you mean, but I think there are two orthogonal issues here. One is the ownership/lifetime of the heap allocation. That is indeed coupled to a stack object, because non-stack bound lifetimes can (with the current state-of-the-art) not be analyzed at compile time. Calling this shoehorning is strange, that's the whole idea of RAII. The other issue is borrows of heap objects, which the borrow checker can of course handle since they are no different than borrows to stack objects.
- roca 7y agoYes, it's very similar to unique_ptr. The point here is that you can implement many kinds of complex and useful heap-allocated data structures in safe Rust code, without any reference counting, and the compiler will verify that you have no use-after-free bugs, or any other kind of memory-safety bug. The same is not true of (pre-SPARK) Ada, or C, or C++, or BetterC.
- pjmlp 7y agoYou can play around with C++ lifetime analysis in Visual C++ 2019 and clang tidy. It is still WIP, yet to be deployed at large, naturally doesn't cover binary libraries, but it already a very good improvement.
- dthul 7y agoIt's exciting to see C++ pick up some of those ideas! Anything that improves the current situation is appreciated.
- pjmlp 7y agoThat is what I see as most valuable contribution from Rust. Even if Rust would fail at large scale mainstream adoption, the fact that the community has pickup up Cyclon and ATS ideas to the point that Swift, OCaml, Haskell, Ada, C++, D, Chapel, ParaSail and eventually other communities started to adopt similar ideas, that alone is a major victory to everyone involved in Rust.
- dthul 7y agoSure it does. The borrow checker is concerned about lifetimes, regardless of whether the object lives on the stack or the heap.
- epage 7y agoThe borrow checker is what is being referred to and has no runtime overhead. Now, an environment without a GC will use ref counting sometimes but it will regardless of C, Rust, or C++
- gmueckl 7y agoReference counting has well known issues that are independent of the programming language: - can't deal with circular references without user intervention - storing the reference counter is hard: either it clobbers a whole cache line or it ruins memory alignment - atomic reference counting has the potential to utterly ruin runtime performance unless it used extremely carefully
- steveklabnik 7y agoThe borrow checker does not use reference counting.
- littlestymaar 7y agoI'm pretty sure you are confusing Rust (borrowck, done at compile-time, no runtime overhead) and Swift (where every object is reference-counted, with some, sometimes big, overhead).
- pjmlp 7y agoIn Rust GUI code is quite common to have Rc<RefCell<>> scattered across all widgets callbacks.
- littlestymaar 7y agoI assume you're talking about GTK or Qt? AFAIK they are the only viable options for Rust GUI at the moment, but their paradigm doesn't fit well with Rust ownership and you need to use ref-counting everywhere as you said. I don't think the problem is inherent to GUI in general though.