This is all well and dandy for some usage scenarios but breaks in others, eg. scene graphs and GUI's.
A scene graph needs 2 mutable references, and has nothing to do with ownership. Same issue exists with GUI's. The pattern that Rust forces is to always request a reference, which incurs a performance penalty while retrieving the same reference again and again and again.
TonyStr 43 minutes ago [-]
I am not familiar with scene graphs, but what is the problem with borrowing or refcounting? This article showed how you can have multiple mutable references in Rust, even multiple mutable references running in parallel threads.
baranul 2 hours ago [-]
Rust is becoming less special in this area. Languages such as Dlang, Vlang, and Julia have added optional ownership and borrowing. As these offerings are optional, many can see this as greater programmer freedom to decide what to use for their projects, with languages that are easier to use or read.
embedding-shape 1 hours ago [-]
> Rust is becoming less special in this area. Languages such as Dlang, Vlang, and Julia have added optional ownership and borrowing
Isn't the crux that Rust does those things without a garbage collector, that's the novel part? Someone correct me if I'm wrong (likely), but I think all those languages have garbage collectors, which Rust doesn't.
baranul 24 minutes ago [-]
> without a garbage collector, that's the novel part?
That's not quite how it works in various languages. You appear to be thinking of the garbage collector as something inseparable from the language.
Both Dlang and Vlang have optional garbage collectors, that can be turned off. In the case of Vlang, none of its libraries depend on the garbage collector. Vlang offers optional (flexible) memory management, somewhat similar to Nim (but they presently don't have optional ownership).
In the case of Julia and Vlang, their optional ownership is new and experimental. Dlang's optional ownership has been around for some years now, showing that it could be done.
Dlang and Vlang allow you to choose the type of memory management (along with some other languages) that you would like to use. Vlang does it by command line flags. You can turn off garbage collection and turn on ownership.
digikata 1 hours ago [-]
Yes, it's a critical distinction that's important in many systems domains, but getting some form of ownership policy and method - even if implemented with a GC I think is a step forward in terms of building reliable code.
The thing about it being optional in some languages is that it's an experiment, but one that as a feature it really pays off the more code in the ecosystem is compliant to ownership tracking. For rust, it's the vast majority of it (with opt out explicitly findable..) For languages offering it optionally, it's harder to assemble the full benefit.
bcjdjsndon 1 hours ago [-]
I guarantee they'll be complaining about unsafe rust in 10-15 years, mark my words. Just like they said exceptions "force" a programmer to deal with all error cases (newsflash, they still ignore it), rust will not eliminate memory errors.
b40d-48b2-979e 36 minutes ago [-]
Rust already has.
ellie_kim98 2 days ago [-]
[dead]
jonathanstrange 3 hours ago [-]
[flagged]
conradludgate 2 hours ago [-]
I miss the clear distinction between exclusive access and shared access when I work in GC languages. Knowing clearly when you are allowed/expected to modify a value, and when you are expected to only read the value ends up being very useful and it has poisoned my brain when working in Python/JS/Go where some values are internally pointers and there's no standard to learn once for when a mutation is safe or if you should always make a copy
quietbritishjim 2 hours ago [-]
One way to deal with this in GC languages is to have a separate read-only view on a mutable object. The example that comes to mind, though it's a bit more complex than a view on a simple data structure is CancellationToken (read only) vs CancellationTokenSource (writable in the sense of having "cancel()" method) in C#. I'm not saying it's better than proper mutability support but it does work well enough sometimes.
zigzag312 3 hours ago [-]
Reference counting is a form of garbage collection.
sieabahlpark 2 hours ago [-]
[dead]
Rendered at 12:09:16 GMT+0000 (Coordinated Universal Time) with Vercel.
A scene graph needs 2 mutable references, and has nothing to do with ownership. Same issue exists with GUI's. The pattern that Rust forces is to always request a reference, which incurs a performance penalty while retrieving the same reference again and again and again.
Isn't the crux that Rust does those things without a garbage collector, that's the novel part? Someone correct me if I'm wrong (likely), but I think all those languages have garbage collectors, which Rust doesn't.
That's not quite how it works in various languages. You appear to be thinking of the garbage collector as something inseparable from the language.
Both Dlang and Vlang have optional garbage collectors, that can be turned off. In the case of Vlang, none of its libraries depend on the garbage collector. Vlang offers optional (flexible) memory management, somewhat similar to Nim (but they presently don't have optional ownership).
In the case of Julia and Vlang, their optional ownership is new and experimental. Dlang's optional ownership has been around for some years now, showing that it could be done.
Dlang and Vlang allow you to choose the type of memory management (along with some other languages) that you would like to use. Vlang does it by command line flags. You can turn off garbage collection and turn on ownership.
The thing about it being optional in some languages is that it's an experiment, but one that as a feature it really pays off the more code in the ecosystem is compliant to ownership tracking. For rust, it's the vast majority of it (with opt out explicitly findable..) For languages offering it optionally, it's harder to assemble the full benefit.