Yes. Rust needs radically more use not to end up fizzling like myriad languages before it. But its stalwarts are hostile to measures to make it easier for people to pick up, even easy ones that do not alter the language at all. (E.g., allowing a debug build to complete despite borrow complaints.) It takes a special dedication to overcome barriers that most of the people it must attract lack.
It was meant to supplant C, but C users, as a rule, are defined by seeing a thousand other languages go by and not jumping. So Rust mostly picks up discontents from other languages, including Java, Go, and, yes, C++.
The danger in appealing to discontents is that they are likely to jump ship for the next shiny thing.
> But its stalwarts are hostile to measures to make it easier for people to pick up, even easy ones that do not alter the language at all. (E.g., allowing a debug build to complete despite borrow complaints.)
That seems like a rather unusual suggestion to me. Are there commonly used languages/situations where optimization level changes semantics/allowed constructs? The only thing I can think of off the top of my head is stuff that relies on tail calls be optimized in languages that don't guarantee tail call optimizations, but I think that's a relatively niche case compared to debug vs. release builds.
I also feel that that suggestion could arguably make the language harder to pick up, since something that worked in debug mode might require extensive refactoring for release mode. Given how much Rust relies on the optimizer to see through its abstractions, that seems problematic.
In addition, I suspect (but don't know for sure) that writing code that works correctly in both modes can be tricky - think of something that uses multiple threads, where "release-mode code" can rely on the lack of mutable aliasing but "debug-mode code" cannot. Either you maintain two versions of the code or you write code that doesn't rely on the borrow checker guarantees, which seems like it would defeat the purpose of having the borrow checker in the first place. This is a gut feeling, though, so I wouldn't be surprised if there were a way around this.
Finally, I'm not sure I agree with the notion that this change "[does] not alter the language at all." It's like the concept of "allowing a debug build to complete despite [type] complaints" in C++. You're going to have to change the language somehow to define the semantics of ignoring type errors, and I'm not sure how this will help newcomers or how easy such a change would be to implement.
Out of curiosity, what other measures did you have in mind? Or can you point me somewhere which discusses similar measures?
It's a little tricky, I think, because lifetimes are a part of the type of things and can determine behavior. But you could possibly do like GHC does with "defer type errors" and panic if you encounter a situation where that might matter (including before an illegal borrow or whatnot). It doesn't really help you solve the bit that was unchecked, but if you're trying to iterate around something earlier in the code it might be useful sometimes to be able to focus on the bit you're working on and put off cleaning up stuff you're not wanting to execute yet anyway.
GCH has a pretty significant head start given that it has lazy semantics and an interpreter.
I don't really see the point of disabling the borrow checker anyway. I assume the intent is that it would make incremental development easier, but as someone who has written probably 100kLOC of Rust I feel like it would take a ton of work to implement (ie: making `miri` radically more powerful and generalizing it) and solve... no real problems for me. I get that a beginner is going to see bigger wins there since they will hit borrow checker errors earlier, but even then, I learned rust in 2015 when the borrow checker was way stricter, and I don't think I fought very much with it - I learned immediately that I could clone my way out of almost any issue.
IMO a far better investment would be into compiler errors giving better hints, or IDE improvements to show lifetimes, etc, and those would all be global wins instead of something rather niche.
> But you could possibly do like GHC does with "defer type errors" and panic if you encounter a situation where that might matter (including before an illegal borrow or whatnot).
I honestly didn't know that capability existed. Just to make sure I'm reading the right thing, is it the technique described in Equality proofs and deferred type errors: A compiler pearl [0]?
I have no training in programming language theory, so I can't give a good evaluation on how applicable this technique is to Rust. The first thing that jumps to mind is that I think it relies on Haskell's laziness to avoid evaluating the thunk (?) representing the type error if it isn't needed, but that's not to say that a different approach can't be found that doesn't require laziness (assuming I read the paper correctly).
That being said, given Rust provides types which defer borrowing checks to runtime (Cell/RefCell [1]), I think it may be possible to implement something similar to -fdefer-type-errors by e.g., wrapping all references in a Cell/RefCell and inserting appropriate function calls. I would guess the main concern there is fragmenting the Rust ecosystem into code that requires a hypothetical -fdefer-borrowck-errors flag and code that works with "standard" Rust, and tying that to optimization level has its own issues.
It's admittedly a bit different than what I had in mind when I first responded to ncmncm's comment (where I interpreted it as "pretend the borrowck errors didn't exist," as opposed to "use runtime checks as appropriate"), but it does make more sense.
Right, but as far as I know those preserve language semantics and are stricter in debug mode than in release mode. The way I interpreted ncmncm's comment was that the suggested build-even-with-borrowck-errors was the opposite - different language semantics, and something that compiles in debug mode won't compile in release mode.
All compilers allow builds that trigger warnings to complete.
Obviously code that only runs when built "debug" differs from released code, which ... doesn't run. That is the whole point. Before you ship, you will resolve all the borrow nags, and then there will be a release build, and it will run the same.
In the meantime, you probably have more urgent worries to act on first. The only difference is who decides when, you or the compiler. As is, the compiler decides, period.
(I confess it utterly mystifies me how this is such a difficult concept for so many. Inability to comprehend something so simple bodes ill for judgment on more weighty matters.)
> All compilers allow builds that trigger warnings to complete.
That is true, but I don't see how it's relevant. Violations of the borrowing rules in Rust are like type errors in C++ or C. Warnings are simply not part of the picture.
> Obviously code that only runs when built "debug" differs from released code, which ... doesn't run.
I honestly don't know what this wording is intended to convey. The text before the edit made more sense.
But in any case, I don't really see the relevance. I asked about situations where the presence/absence of optimizations changes language semantics. As far as I know, programmers generally expect that the same code will exhibit the same observable behavior regardless of whether it was built in debug or release mode (i.e., the as-if rule, barring UB/IB/etc., of course). What you're suggesting appears to violate that - something that builds in debug mode may not compile at all in release mode, let alone run the same. How is that better for newcomers?
> Before you ship, you will resolve all the borrow nags, and then there will be a release build, and it will run the same.
This feels like it's doing a lot of hand-waving. By way of analogy:
"Before you ship, you resolve all the type nags, and then there will be a release build, and it will run the same"
If you started with a program where everything is a void*, "resolve all the type nags" is potentially a huge amount of work. There's absolutely no guarantee that you will only need to make "minor" changes to get your program working in release mode. Maybe what you wrote is good enough, maybe you need to completely restructure your program. That certainly does not sound very newcomer-friendly to me.
> In the meantime, you probably have more urgent worries to act on first. The only difference is who decides when, you or the compiler. As is, the compiler decides, period.
Couldn't this argument be extended to other aspects of a program that can be statically checked? Why stop at the borrow checker?
You demonstrate that anybody can fail to comprehend anything, howsoever simple, if they dedicate enough effort. What such failure indicates is obscure.
(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?)
It does suggest that the prospect of Rust ever being made more accessible to new users is slim to none, as, thus, is displacing C enough to move any needle, more's the pity.
We will need to rely on people graduating to use of modern C++, instead.
> (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.
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.
> 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.
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.
> 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?
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?
C++ is not the language in daily imminent danger of fizzling. Its proven value makes it worth picking up by thousands of people each week, year in and year out. More pick up C++ for professional use in any such week than the total employed coding Rust.
Rust is the language that, if not adopted fast enough, will pass its sell-by date and fizzle, like so many languages before it. Its true fans should be pulling out all the stops to try to make it easier to adopt. Instead, most do their utter best to prevent wider adoption, containing it as much as possible to the ragged few like themselves willing to tolerate any infelicity.
Rust's fate will be chosen by fans' actions, not their beliefs. Those actions are its doom. Judging by those, Rust will end up yet another potentially interesting language that never took off. I will know whose fault that was.
I mean I get what you are saying about how old stuff doesn't have adoption issues. But, rust is a pretty unique paradigm. The safety guarantees it offers aren't found in other languages without garbage collectors.
Rust is boring and technical. Boring in the "it just works and when it doesn't it's not hard to figure out why" way. You didn't say this, but for others passing by, it would be a mistake to view rust as a "shiny thing". People use it for a reason, barring syntax entirely.
In a lot of cases I would consider a staged rewrite. Ie, I would turn what I could into dylibs going either from rust to c++ or c++ to rust. Assuming the code has structure and isn't infinite singletons and free standing functions this can make more or less sense. I'd translate the parts with the most likelihood for memory safety or thread safety issues first, so the transition could be part of the release cycle.
It would still be a lot of work, but you might see benefits at intermediate releases this way.
They are? That's weird. Rust and C++ have tons in common and Rust takes tons of inspiration from C++, lots of Rust developers (on the compiler/ early Mozilla adopters) were C++ developers before. C++ still comes up often, like in discussions on constexpr vs const fn.
I've also never seen anyone say that Rust is closer to C than C++, that also seems weird.
The argument that Rust is closer to C than C++ is usually not how it is raised in most discussion around complexity and similarity. Also, to be clear, the discussion is usually centered around ‘a replacement for C’ or ‘why Rust is not a C replacement when compared to <insert-other-language>’. From my massive forum lurking habit, at multiple places, the argument seems to be closer to the following:
Person 1 says, “Zig is a viable C replacement, Rust is a C++ replacement.”
Person 2 responds, “Rust is absolutely a C replacement, Rust is so much more simple than C++, that they should not be compared. That simplicity, which is much closer to C than C++, is why Rust should be viewed as the ultimate C replacement.”
So, it’s not a clear cut statement that Rust is closer to C than C++. However, I certainly have taken that as the argument in most discussions I have seen.
Rust is not, in fact, much simpler than C++, and gets less so every release. In five years Rust will be obviously, fully as complex as C++ -- provided it is still used.
Maybe it is my stockholm syndrome of reaching out to C++ when I need something like it alongside my managed languages, but I definitly find template metaprogramming easier to follow, specially since constexpr and concepts, than the various kinds of macros available in Rust.
To keep from fizzling out, Rust has to be much better than what it is trying to compete with, so pointing to something similar in an established language falls short.
In any case, C++20 has Concepts, which where used clear up the template error problem.
I've talked with people in the rust community about modern c++ being similar to rust. They all agreed and honestly thought it was cool. Maybe 1 out of 50 rust programmers language bash and are ignorant, those people tend to be junior and are trying to learn. Everyone else is cool.
That said rust is pretty different from c++. Most people don't compare rust to c because c is so heinously unsafe and rust being the polar opposite. Ironically, rust was indoctrinated as the second supported language to the Linux kernel, alongside C. So they have that in common...
I wouldn't make too many assumptions about the rust community, they are pretty nice smart reasonable people who tend to write c/c++ for work...
It was meant to supplant C, but C users, as a rule, are defined by seeing a thousand other languages go by and not jumping. So Rust mostly picks up discontents from other languages, including Java, Go, and, yes, C++.
The danger in appealing to discontents is that they are likely to jump ship for the next shiny thing.