My instinct says 'yes'. But i also have a feeling that im going to run into problems that current languages dont have. Such as being forced to copy data or have complex systems like in rust to make the compiler happy.
I'm unsure what you mean here. It's pretty foundational to the structuring of programs hierarchically (eg, trees own their children, functions own their variables, closures own their environments, and so on).
The classic argument against ownership as a language semantic is that it doesn't play well with graphs and circularly linked lists, where there isn't a meaningful hierarchy and therefore no one ancestor is the "owner" of any descendant. The counterargument is that these datastructures are both rare and better represented with a single owner of the data and the relationships represented through indirection even if your implementation language doesn't enforce ownership (for example, adjacency lists/matrices for graphs, vectors for lists, etc).
Interesting arguments. Thanks.
Similarly, having a clear idea of ownership can help in writing GC friendly code.
For a higher level hobby language I’m designing, I’m thinking of doing a similar concept, but with runtime overhead - basically every object would be “synchronized” in Java’s parlance, but to make it efficient most lockings would be elided at compile time via move semantics. So data races couldn’t happen (also, could possibly do a better job at escape analysis).
The primary reason I’m thinking about that is that we really shouldn’t be using non-thread safe primitives anymore — Clojure did get this right. That should be left as a compiler optimization if it can prove that that given code runs inside a “alone”.
Not if you live in a communist society.
I think it would be better if there was no ownership, because everybody would be happy.
It means no private ownership of the means of production, which another can of worms.
This article explains the uniqueness/mutability relation well, but it uses the terms "variable" and "value" with different meanings than most programmers would use. What the article calls "value" I would call "memory location" (maybe one could even call it "variable"); and what it calls "variable" isn't 100% accurate but I guess it works to keep the explanation simple.
Have to disagree on this, these are very common words with normal meanings, from the Assignment page on Wikipedia:
> Assignments typically allow a *variable* to hold different *values* at different times during its life-span and scope
https://en.wikipedia.org/wiki/Assignment_(computer_science)
Unless there's something I'm missing, this is exactly how Matt is using those words.
Models where the value `1` in `let x = 1` gets a memory location - they unnecessarily mix in details about where the value is stored. In most cases, the value is not stored anywhere, neither stack nor heap etc, that is just a value and the compiler and compiler settings determine what happens next. A common case is that it's constant folded into some operation, so the `1` then doesn't have any relationship to memory at all.
I think the terms used are typical for Rust. Doesn't each language have its own terms? The C standard's object is not the same as Python's object and so on.
Value is OK.
The "value" and "variable" naming is unambiguous though. "Variable" might be problematic for someone that conflates the concepts of reference and value - but that's an issue that should be solved far earlier than ownership.
You can indeed create data races with them, but only in combination with unsafe code.
It’s not clear what your question is.
You can use unsafe to write unsound code which suffers from data races.
If you use safe Rust, then you should not suffer from data races (and fences only add constraints, so they can’t add data races, they’re tools to avoid those), although bugs are always possible and sometimes purportedly safe stdlib APIs are found to be unsound (that’s one of the few things for which the rust project allows breaking backwards compatibility, though even that depends on the blast radius e.g. std::mem::uninitialized is still there, just deprecated, even though there’s almost no way to use it soundly).
