A comparison of Rust's borrow checker to the one in C#
A comparison of Rust's borrow checker to the one in C#
Cool, that was an informative read!
If we were willing to leak memory, then we could write […]
Box::leak(Box::new(0))In this example, you could have just made a constant with value
0and returned a reference to that. It would also have a'staticlifetime and there would be no leaking.Why does nobody seem to be talking about this?
My guess is that the overlap in use cases between Rust and C# isn’t very large. Many places where Rust is making inroads (kernel and low-level libraries) are places where C# would be automatically disqualified because of the requirements for a runtime and garbage collection.
(Note that I'm not the article author)
In this example, you could have just made a constant with value
0and returned a reference to that. It would also have a'staticlifetime and there would be no leaking.I believe the intention was to demonstrate something that works with runtime values too, and a constant 0 does not.
Btw you can just write
&0to do what you proposed, there's no need for an explicit constant/static.
That is interesting and I didn't know C# had anything like that. I saw another article recently saying at some point we were likely to see Rust get garbage collection.
Would you have a link to that? I know there are many third-party garbage collectors for Rust, but if there’s something semi-official being proposed or prototyped I’d be most curious :)
It's not official or semi-official, it was just someone (a well known Haskell guru if that matters) speculating in a blog post.
The reason is the vast majority of places use c# to avoid this stuff. So performance is often not the first priority
The complexity it adds takes away from the readability and maintainability. Which is often the priority.
But in a hot path where you need optimization these are a good send as previously you had to use raw pointers and completely side step all the safety of the language.
I would say 90% of c# developers will never touch these. It's more for library and framework writers.
I believe most of these features are driven by what the Microsoft Devs need to write asp.net and EF.
Yeah I had thought that C# was basically Microsoft's version of Java, GC'd throughout. But it's fine, I'm not particularly more excited by it now than I was before (i.e. unexcited). I'm not even excited by Rust, but maybe I'm missing something. I think it's fine to use GC for most things, and program carefully in a non-allocating style when you have to, using verification tools as well.
A classic: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html
Is what the author calls a C# borrow checker purely lexically based? The first error message gives that impression. And if it is, then it wouldn't qualify for any such comparisons with 2018+ Rust.
It's 100% not a borrow checker because c# doesn't have borrowing. It's just static analysis to ensure memory safety. But the author acknowledges that.
It's just checking the scopes the variables are defined in in the first example.
It's a very different kind of borrow checking than Rust's. For example there's no mutability xor sharing checking, because mutability cannot invalidate memory (there's still a GC in C# after all!). As such, Rust's NLL (which are available in the 2015 edition too btw) don't really make sense in C#.
I found it hard to follow despite C# being my main driver.
Using
ref, in the past, has been about modifiable variable references.All these introductions, even when following C# changes across recent versions, were never something I actively used, apart from the occasional adding ref to structs so they can contain existing ref struct types. It never seems necessary.
Even without ref you use reference and struct types, where reference content can be modified elsewhere. And
IDisposablefor object lifetimes with cleanup.