4 ms·

> (Is it really so hard to understand how a program that exists and can be executed differs from the entire lack of any such program?) No, but again, I don't s

> (Is it really so hard to understand how a program that exists and can be executed differs from the entire lack of any such program?) No, but again, I don't see the relevance here. What I have been trying to say is simple: tying language semantics to the presence or absence of optimizations is going to pose challenges that could easily overshadow any potential advantages a more "relaxed" debug mode might provide for newcomers. Suggesting that the borrow checker be able to be "turned off" is not novel, but the idea of tying it to optimization level is, and that is what I have been trying to discuss, without much success.

ncmncm 4y ago
If you really imagine that "debug" vs. "release" building is about optimization, I don't know what to suggest for you. Nobody has proposed "turning off" the borrow checker. This is another red herring always thrown up. Nobody has proposed "turning off" the borrow checker. Maybe imagining somebody did is your trouble? But I doubt it. At some risk of triggering another massive incomprehension storm, you might better compare the suggestion to turning const violations in non-release builds into warnings (while imagining that over-aggressive intolerance of const violations was driving away potential users). Yes, fixing your const violations before release might be a chore, even a big chore, but it should be very, very easy to imagine other actual program logic problems that might be tackled entirely independently of them. The code with the const violations in might end up deleted, in the process, so that being obliged to fix them first would have been a pure waste of effort.
- aw1621107 4y ago
  > If you really imagine that "debug" vs. "release" building is about optimization, I don't know what to suggest for you. I mean, if you really want to be pedantic about it, "debug" vs. "release" means precisely nothing since they can be arbitrarily customized. However, in the context of this comment chain (newcomers to Rust), who are likely to be using cargo in its default configuration, "debug" vs. "release" primarily comes down to optimization settings and the generation of debug information, neither of which change program semantics for the most part. The only exception is overflow checking, which is disabled in release mode. While I'll freely admit this does weaken my argument, I assert it doesn't suffer from the main flaw that yours does, in that debug mode is less lenient with respect to overflow checks, and turning them off for release mode doesn't cause compilation errors. This is significantly more friendly to newcomers, though I still think the semantic difference between debug and release is not ideal. > Nobody has proposed "turning off" the borrow checker Nobody in this thread? Sure. Nobody on the Rust dev team? Also sure. I assert (albeit without evidence, unfortunately, though I suspect you know better than I do) that that sentiment is not that uncommon among newcomers, though. In any case, I think you're reading my comment too literally (though that's partially my fault for being unclear). The intended meaning was that adding some way to "bypass" borrow checker errors is not new, whether by literally "turning off" the borrow checker or through some other mechanism as in your proposal. > you might better compare the suggestion to turning const violations in non-release builds into warnings (while imagining that over-aggressive intolerance of const violations was driving away potential users). Yes, this is one possible comparison, but as I stated in previous comments, an analogous comparison applies to every other statically-checkable property, and I would argue that they all face the same issue: that what you write in "debug" mode may be unusable in "release" mode, which does not seem like a good experience for a newcomer. In addition, there's the question of why the argument should stop at the borrow checker - why not also have a mode which allows a program to compile despite the compiler complaining about type errors (which is a superset of const violations)? So in the end, yes, I can imagine ignoring one set of problems allowing a programmer to focus on another set of problems. I can also imagine solving one set of problems by ignoring another resulting in an entirely useless solution because the ignored problems are actually/incidentally important, in which case the ability to compile code in an "intermediate" state is cold comfort. Maybe preventing said intermediate code could have clued in the programmer that the solution they were headed towards was unfeasible, as well. Hard to say how this tangle of hypotheticals turns out.
  - ncmncm 4y ago
    Type violations mean the compiler doesn't know what code to generate. That would not apply to const violations, and likewise would not apply to borrow violations. Where in fact the borrow violation would result in a buggy program, the compiler has already issued its warning. But all this is moot. It is clear that the overwhelming sentiment is that not even the tiniest change to make Rust easier for new people to adopt should find sensible consideration. Thus, Rust will see too little adoption to forestall fizzling, with the full approval of its most ardent fans. I will be sad to see that happen.
    - aw1621107 4y ago
      > Type violations mean the compiler doesn't know what code to generate. I'm not sure this has to be true. While I'm not sure how a compiler might deal with something like std::vector<int> v = some_unordered_map with the existing language semantics, something like working with technically-incompatible pointers might be malleable enough to work with. In such a case, the compiler knows how to generate otherwise-appropriate code, but according to the language rules it can't. Ignoring the type error in this case could mean just generating the code anyways and letting the cards fall as they may, much like what may be done for const or borrow violations. > It is clear that the overwhelming sentiment is that not even the tiniest change to make Rust easier for new people to adopt should find sensible consideration. Are there other language which make similarly-situated concessions to newcomers?
      - oncewas 4y ago
        This argument that rust is complicated is really tiring and laughable in the face of c++'s complexity. Rust has the biggest concession to newcomers I have ever seen offered, it will not let you compile code that contains many commonly encountered show stopping confusing as sin errors... The person claiming this, is in the same breath claiming that a book written by experts is not worth reading. Assuming ncmncm is an expert at c++: How confusing does a language have to become for that to even happen?
        4y ago

ncmncm 4y ago

If you really imagine that "debug" vs. "release" building is about optimization, I don't know what to suggest for you. Nobody has proposed "turning off" the borrow checker. This is another red herring always thrown up. Nobody has proposed "turning off" the borrow checker. Maybe imagining somebody did is your trouble? But I doubt it. At some risk of triggering another massive incomprehension storm, you might better compare the suggestion to turning const violations in non-release builds into warnings (while imagining that over-aggressive intolerance of const violations was driving away potential users). Yes, fixing your const violations before release might be a chore, even a big chore, but it should be very, very easy to imagine other actual program logic problems that might be tackled entirely independently of them. The code with the const violations in might end up deleted, in the process, so that being obliged to fix them first would have been a pure waste of effort.

aw1621107 4y ago
> If you really imagine that "debug" vs. "release" building is about optimization, I don't know what to suggest for you. I mean, if you really want to be pedantic about it, "debug" vs. "release" means precisely nothing since they can be arbitrarily customized. However, in the context of this comment chain (newcomers to Rust), who are likely to be using cargo in its default configuration, "debug" vs. "release" primarily comes down to optimization settings and the generation of debug information, neither of which change program semantics for the most part. The only exception is overflow checking, which is disabled in release mode. While I'll freely admit this does weaken my argument, I assert it doesn't suffer from the main flaw that yours does, in that debug mode is less lenient with respect to overflow checks, and turning them off for release mode doesn't cause compilation errors. This is significantly more friendly to newcomers, though I still think the semantic difference between debug and release is not ideal. > Nobody has proposed "turning off" the borrow checker Nobody in this thread? Sure. Nobody on the Rust dev team? Also sure. I assert (albeit without evidence, unfortunately, though I suspect you know better than I do) that that sentiment is not that uncommon among newcomers, though. In any case, I think you're reading my comment too literally (though that's partially my fault for being unclear). The intended meaning was that adding some way to "bypass" borrow checker errors is not new, whether by literally "turning off" the borrow checker or through some other mechanism as in your proposal. > you might better compare the suggestion to turning const violations in non-release builds into warnings (while imagining that over-aggressive intolerance of const violations was driving away potential users). Yes, this is one possible comparison, but as I stated in previous comments, an analogous comparison applies to every other statically-checkable property, and I would argue that they all face the same issue: that what you write in "debug" mode may be unusable in "release" mode, which does not seem like a good experience for a newcomer. In addition, there's the question of why the argument should stop at the borrow checker - why not also have a mode which allows a program to compile despite the compiler complaining about type errors (which is a superset of const violations)? So in the end, yes, I can imagine ignoring one set of problems allowing a programmer to focus on another set of problems. I can also imagine solving one set of problems by ignoring another resulting in an entirely useless solution because the ignored problems are actually/incidentally important, in which case the ability to compile code in an "intermediate" state is cold comfort. Maybe preventing said intermediate code could have clued in the programmer that the solution they were headed towards was unfeasible, as well. Hard to say how this tangle of hypotheticals turns out.
- ncmncm 4y ago
  Type violations mean the compiler doesn't know what code to generate. That would not apply to const violations, and likewise would not apply to borrow violations. Where in fact the borrow violation would result in a buggy program, the compiler has already issued its warning. But all this is moot. It is clear that the overwhelming sentiment is that not even the tiniest change to make Rust easier for new people to adopt should find sensible consideration. Thus, Rust will see too little adoption to forestall fizzling, with the full approval of its most ardent fans. I will be sad to see that happen.
  - aw1621107 4y ago
    > Type violations mean the compiler doesn't know what code to generate. I'm not sure this has to be true. While I'm not sure how a compiler might deal with something like std::vector<int> v = some_unordered_map with the existing language semantics, something like working with technically-incompatible pointers might be malleable enough to work with. In such a case, the compiler knows how to generate otherwise-appropriate code, but according to the language rules it can't. Ignoring the type error in this case could mean just generating the code anyways and letting the cards fall as they may, much like what may be done for const or borrow violations. > It is clear that the overwhelming sentiment is that not even the tiniest change to make Rust easier for new people to adopt should find sensible consideration. Are there other language which make similarly-situated concessions to newcomers?
    - oncewas 4y ago
      This argument that rust is complicated is really tiring and laughable in the face of c++'s complexity. Rust has the biggest concession to newcomers I have ever seen offered, it will not let you compile code that contains many commonly encountered show stopping confusing as sin errors... The person claiming this, is in the same breath claiming that a book written by experts is not worth reading. Assuming ncmncm is an expert at c++: How confusing does a language have to become for that to even happen?
      - 4y ago