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.
7 Likes
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.
4 Likes
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.
8 Likes
Exactly.
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.
1 Like
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.
7 Likes
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 
1 Like
Topic: "Linux Developers May Discuss Allowing Rust Code Within The Kernel" by Almindor
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.
Source: Linux Developers May Discuss Allowing Rust Code Within The Kernel - Phoronix Forums
I don't think we should be linking to the Phoronix comments section, no matter what someone says there.
4 Likes
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.
11 Likes
Empowering is the perfect word to describe Rust in 2020. What used to be a rough adventure with many pitfalls has turned into something beautiful, something that can lift your spirit. At least, that’s what it did for me.
Mathias Lafeldt in Giving Rust Another Shot in 2020 | Mathias Lafeldt
9 Likes
If you've never tried Rust, imagine pair programming alongside a nearly-omniscient but narrowly-focused perfectionist.
20 Likes
14 Likes
I'll admit, I've sat at my desk with a huge smile thinking "I couldn't have built this without lifetimes."
5 Likes