Rust's beauty lies in the countless decisions made by the development community that constantly make you feel like you can have ten cakes and eat all of them too.
-- Jake McGinty et al on the tonari blog
References are a sharp tool and there are roughly three different approaches to sharp tools.
- Don't give programmers sharp tools. They may make mistakes and cut their fingers off. This is the Java/Python/Perl/Ruby/PHP... approach.
- Give programmers all the sharp tools they want. They are professionals and if they cut their fingers off it's their own fault. This is the C/C++ approach.
- Give programmers sharp tools, but put guards on them so they can't accidentally cut their fingers off. This is Rust's approach.
Lifetime annotations are a safety guard on references. Rust's references have no sychronization and no reference counting -- that's what makes them sharp. References in category-1 languages (which typically do have synchronization and reference counting) are "blunted": they're not really quite as effective as category-2 and -3 references, but they don't cut you, and they still work; they might just slow you down a bit.
So, frankly, I like lifetime annotations because they prevent me from cutting my fingers off.
Rust is like a futuristic laser gun with an almost AI-like foot detector that turns the safety on when it recognises your foot
Ownership in Rust is entirely a type system fiction.
I'm not sure what is meant there. "ownership" in many languages is a very real thing to me.
For example in C++ you might create an object and then you have a pointer to it. At some point you have to "free" that object else you have a memory leak.
You might pass that pointer around to other functions and threads in your system. At some point someone has to "free" it. But who? Not necessarily the creator of the object. Hopefully at least the last user of the object, else you have a dangling pointer reference.
One has to take account of this ownership problem when building a C++ program to avoid big problems. Even if the language itself does not have a way to express ownership. Similarly for other compiled languages. Heck, even assembler.
AI are fallible. I would say it's a property of space-time that makes the distance infinite between any gun and any foot. You need to build unsafe wormholes to bypass it.
I misread this as "Ownership in rust is type science fiction" - and for me that's bang on the money. Rust programming is sci-fi except it's here now.
My understanding is that "Ownership in Rust is entirely a type system fiction." is a fancy way of saying that, if you look at the generated machine code, you can't "point at the ownership".
It's purely a constraint on which programs will be allowed to compile, similar to how machine code has no concept of variable types. They're just constraints in the compiler so you can't accidentally call the floating point addition opcode on bit patterns representing integers without first specifying how to reconcile the two.
When you think about it, a lot of higher-level programming constructs are fictional in the same way. What's a string? It's a pointer to a memory block of a known size where we expect those bits to mean a specific thing. The hardware doesn't care.
Well, let's think about it some more...
Our so called computers have no numbers, not signed or unsigned or otherwise. They have no operations like ADD, SUB, MOV on those non-existent numbers.
They are just collections of atoms, mostly silicon now a days, interacting with each other.
Which we humans interpret as doing something meaningful and perhaps useful.
That might be an extreme view of things but I say it only to point out that there are many layers of abstraction to this "reality" we all live in. Most of it constructed in our minds.
So when I said, "ownership in many languages is a very real thing to me". I did indeed mean "real" as in the fictional abstraction word of high level programming languages. For example in C, C++, Pascal, PL/M etc. It is a thing you have to think about if you want your program to be robust, even if those language specifications never mention it.
I am late to the party, and others already answered this, but here is how I would put it: when defining (formally and precisely) what a Rust program does when it executes (the "operational semantics" of Rust), the notion of "ownership" does not come up. So in the sense that the only aspect of a program that actually "exists" is its behavior when executed, ownership "does not exist".
This goes beyond looking at the machine code. When looking at the machine code, you cannot see Undefined Behavior, and yet Undefined Behavior is part of Rust's "operational semantics". Ownership, on the other hand, is not.
Put differently, if you already knew that a Rust program is well-typed, you could write a compiler for it where ownership plays no role whatsoever. Or alternatively, think of Miri but assume we already know the program is well-typed -- again, Undefined Behavior still "exists", as does borrowing to some extent (due to Stacked Borrows), but ownership does not.
That is an interesting variety of perspectives on "ownership" that have been posted here.
I was looking at it like this:
If my program crashes or produces wrong results that is a very real result to me. It may have very real consequences. Be it causing a plane to crash, a pace maker to fail, a financial loss, a security vulnerability, etc, etc, etc.
The cause of those very real outcomes must be something real in turn. Like my failure to abide by ownership rules in languages like C, C++. PL/M, Coral, Pascal etc, etc. Even if those languages have no notion of "ownership" written into their specifications.
But it's not failure to uphold "ownership" that causes a crash. It's use-after-free, double-free, or even logic errors. Ownership is a technique (enforced by Rust's borrow checker) that ensures you meet the dynamic requirements of the system, not the requirement in and of itself. It's in that way that ownership is a "fiction;" the actual dynamic model of the code has no care about whether you follow the ownership "pattern" or not, just that you meet these more simple requirements.
But we've derailed this thread more than enough already
Topic: "Linux Developers May Discuss Allowing Rust Code Within The Kernel" by
I definitely wouldn't use Rust for some tasks but embedded, systems/kernel programming, drivers and some back-end stuff is where I think it brings SO much to the table it'd be crime not to use it.
I don't think we should be linking to the Phoronix comments section, no matter what someone says there.
Humor by @FedericoStra in response to
unsafeRust is all about flirting with UB but never giving in.
Once you realize that the Rust borrow checker is actually preventing you from writing bug after bug, you start to wonder how we ever got this far without it.