Hacker News new | ask | show | jobs
by cm3 3777 days ago
Why is move the default? In many code bases the number of immutable references outweighs that of pointers.
3 comments

In early rust, you actually did need to explicitly write `move` to move a value. However, this was extremely annoying as you move values a lot so moving was changed to be the default, which is far more tolerable.

EDIT: There still is a `move` keyword, but it is used to indicate that closures should take ownership of their environment vs. just borrow values from it, not to move individual values.

That way the syntax is the same everywhere. Reference by default would look different, and then you'd need a sigil for move, etc.

pcwalton said that back in the 0.1 days this was actually implemented, and it was very confusing.

I remember it but the language changed so often that I didn't recall this right away. At least it's tried and scrapped and not based on some opinion.
I mean, like in Haskell the hard earned wisdom is that laziness should probably have been opt-in like OCaml making you write the rec keyword for recursive functions. I hope that one day we will get TCO in Rust as it's natural to implement many things recursively.
> in Haskell the hard earned wisdom is that laziness should probably have been opt-in like OCaml

is it? I am no haskeller, but I think I have seen some presentations or read papers in which lazyness by default was mentioned as something that haskell got right.

Do you have some links to read up on what you say?

For me at least, it's nice to have a language feature which tells me "BTW, the borrow checker is about to start caring about how long this memory is around." As opposed to the opposite, which is that everything you ever do will trigger the lifetime checks for passing arguments, and you would have to explicitly tell it to go away and that you want ownership to move.

Edit: I'm referring to the `&` operator which creates a reference/pointer to the memory it precedes.

You mean it's forcing you realize this and restructure your code to free resources early like an eager collector?
That's one pleasant effect (although a bit orthogonal to what I was referring to), because my default behavior in Rust is to pass ownership which results in that memory being dropped as soon as it's no longer needed.

I guess what I'm referring to is that I think reasoning about the borrow checker is easier when references are opt-in instead of being the default. That behavior is re-enforced by the fact that the language's default is ownership. So I only end up needing to think hard about the lifetime of a variable when I've decided to (or been explicitly forced to) use references. I think it's a good way to reduce the cognitive burden of an already unfamiliar mechanism.

EDIT: This also gets at one of my favorite parts of Rust: so many choices have been made in designing the language and standard library that make it so easy to do things "the right way" (either through those things being the default, or making it hard to do stupid things, etc.).