[steveklabnik]

  > seemingly arbitrary rules

Most of them are about Rust's core guarantee: data race freedom. Some of them are due to a certain conservativeness of any static analysis, and may be relaxed in the future.

  > for the love of all that is holy, prove me wrong

It depends on exactly what you're doing. There are always ways to get around things, but it can depend on knowing Rust and its standard libraries well. As a younger language, some patterns are still being developed, and aren't always as obvious as they could be. We'll get there...

Rust is certainly a different language, and if you try to port C++ code directly over, you may have problems. Such is life. :)

[Manishearth]

> Most of them are about Rust's core guarantee: data race freedom

IMO this is just a part of it (and I think you agree, based on previous conversations). The actual thing is that the rules enforce a discipline about data, similar to the discipline in functional languages (except here it's allowing sharing XOR mutation instead of forbidding mutation entirely). This discipline gets us many things -- memory safety, safety from iterator invalidation-y things (there's a whole class of memory safety bugs that happen when you modify the exterior of a things whilst holding a pointer to the interior -- from iterator invalidation to invalidating pointers to a vector after truncation to invalidating enums), and clarity in code. Whilst the chronology of it's design may not be such, I personally look at data race freedom as something we got for free from this discipline, instead of the core focus of it.

[dbaupp]

I strongly disagree: the goal with Rust is to offer safe, low-level programming, not to be a test-bed (or whatever) for some programming paradigm. The "discipline" is just a tool to reach the goal. You can see this in the evolution of Rust: the goal hasn't changed, but the tool used to (try to) reach it has. (I know that you mention ignoring the chronology, but ignoring the intent doesn't make sense.)

Put another way: Rust isn't aiming to be top of the pack in terms of enforcing a certain programming style, where as it is aiming to be top of the pack in terms of safe systems programming. (It might happen to be the best language for the former, but that is a consequence of the latter, not the other way around.)

[Manishearth]

You misunderstand me: I don't disagree that Rust is all about safe systems programming. I disagree that "data race freedom" is Rust's (only) core guarantee, and I disagree that the "seemingly arbitrary rules" are about "data race freedom". They're about so much more, since the same rules get us memory safety as well, among other things.

I don't think that Rust is trying to test out a programming paradigm or whatever, I'm saying that these "seemingly arbitrary rules" get us a lot of things, by proxy of a certain paradigm, and reducing it to "data race freedom" (when it's so much more) is something we should avoid.

(My comment seems to focus on the discipline, I was just using it as a proxy for all of the things it gets us)

[dbaupp]

As we discussed on IRC, "data race freedom" is equivalent to guaranteeing memory safety, and so, in a kind-of pedantic way, data race freedom is the core guarantee. That said, the original comment would've been better phrased as "one of Rust's core guarantees".

Furthermore, I still think the best phrasing of the rules is for that guarantee: if a rule is removed one can usually construct fairly simple programs that have data races/memory unsafety. Of course, it is definitely true that the arbitrary rules have other benefits, but if there was a simpler scheme that gave the core memory safety without the other things, I think Rust would've adopted it.

[yakcyll]

Definitely! I'm just hoping for this 'aha!' moment, since it just feels like black magic for me.

I think conservative approach to fundamentals is a great way to build a robust language and the way it's presented to me suggests that's one of the objectives; however, for an outsider with experience in other, more lenient (and, obviously, bug-prone) languages, those constraints might appear too restrictive. I believe it's a transitional feeling though, hence calling them 'seemingly' arbitrary.

[steveklabnik]

Totally. I'm actually re-doing all of the docs on this stuff right now, I hope that the next iteration will maybe make it easier to grok. We'll see!