And yet converting code to Rust is hard. It is very tough to convert object-oriented C++ code to Rust. The models are too different.
I honestly think it's the other way around.
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.
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?
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.
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.
Thanks for showing me something new!
[0]: https://www.microsoft.com/en-us/research/uploads/prod/2020/0...
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.)
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?
(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.
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.
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.
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.
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.
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?
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?
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.
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.
Take a massive codebase like Libreoffice. How would you even start to migrate this to Rust?
It would still be a lot of work, but you might see benefits at intermediate releases this way.
I've also never seen anyone say that Rust is closer to C than C++, that also seems weird.
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 needs to compete with ISO C++ current, not ISO C++98.
In any case, C++20 has Concepts, which where used clear up the template error problem.
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...
Look at the first comment here: https://news.ycombinator.com/item?id=18037566
And there's a pattern matching proposal: https://news.ycombinator.com/item?id=21933590
And CJJ23 only just added `string::contains`, `string::starts_with` and so on after Rust had them. Coincidence? I think not! (j/k obvs.)
for clown in clowns
This is pretty different from how C++ iterators work:
for (auto clown = clowns.begin(); clown != clowns.end(); ++clown)
So, to "try to compete" we'd expect Rust to adopt the C++ features here right? But instead, in C++ 20 now you can write:
for (auto clown : clowns)
Notice that, as so often, to get here C++ has to add layers of hacks. In Rust clowns is simply any type that implements IntoIterator. That's all, this feature is just syntax sugar and you can implement it yourself calling std::iter::IntoIterator::into_iter(clowns) and then looping over the resulting iterator -- but C++ has not only explicit handling for the range feature here, it also needs two extra special cases to handle the broken C++ built-in array type and the C++ initialiser structures so that these both do what you expect.
So, five years later, and with extra hacks, C++ gives you the same feature as Rust, and we are to believe that C++ isn't the one trying to compete?
Range based for loops were introduced in C++11 (technically C++11 was published in 2011, but almost all compilers supported this way back in 2008-2009) and it's also nothing more than syntactic sugar. In order to provide support for a type T you need the following functions, which can be free functions or member functions:
begin(T&)
end(T&)
++(decltype(begin(T&)))
The only hack I can think of related to your post is that if T is an array, it uses the free functions std::begin and std::end which are overloaded to work with C arrays.
Little of what "tialaramex" writes is correct, and none of substance.
This is not exactly true. For example, with the introduction of smart pointers, manual memory management is kicked out of C++'s happy path. This makes code far simpler to reason about and safer. Sure, you can still use new and delete, but since C++11 you better have a very good reason to use those.
Nevertheless, it doesn't make sense to complain about not deleting stuff from C++ when a) until recently C++ was repeatedly criticized for having an extremely spartan standard library, b) since C++98 basic features were added to C++ such as support for parallel and concurrent programming, c) there is no feature that gathers anything resembling a consensus on beig worth taking out of the standard.
I'd add that pseudo-standard libraries for C++, such as Boost and POCO, have been popping up and growing in both scope and adoption. This reflects a clear need felt by the C++ community to increase the scope of it's standard components.
Irrelevant. C++'s smart pointers deal with ownership and life cycle management. You can still pass raw pointers to objects managed by a smart pointers.
The only exception is when you're dealing with a framework which already handles life cycle management, such as Qt. Nevertheless, even Qt offers its own smart pointers suite.
Not if the API is taking ownership and you want your program to be correct. This happens far more often than dealing with something like Qt.
Not really. The very, very, very important difference is that the pointer can be null, signalling "no object". For some purposes, this is a critically important difference; in other cases, you should be passing a reference.
> Learn to embrace the pain.
Judging by how much I suffered just to try to implement a sqrt function generically I think that is not an exclusive C++ thing.
> And yet converting code to Rust is hard.
Exactly, that is why many many projects will remain in C++ for a long long time.
Some projects will be coded in other languages, and stay in those languages. Wherever that language fizzles, the project will too.
Anybody who believes this ought to think it an excellent reason to stay away from C++. For actual software projects I mean. Obviously if you want a career writing books (like the one reviewed) or on the conference circuit, or training, or several other prospects, this is great news. C++ is a good language it which to charge somebody $1000 per day plus expenses to tell them what they already knew.
But if you actually write software, or worse, if you need software but that isn't really what you actually wanted to do just a necessity like farmers need to know how to drive a tractor, then this ought to put you off. C++ doesn't want to be your best choice, according to ncmncm anyway, it wants to be a trap you fall into and can't get out of. Run away!
So, the advice above is just to avoid all languages (which, by the evidence, he does, seeming to know nothing meaningful about any).
There is an exception, though. Projects in C have frequently transitioned to C++, often with great success, notably Gcc and Gdb.
For example, the current c++ project I work on (for a large company) has over 1.5 million lines of c++, spanning over 5,000 files, with business knowledge and bug fixes spanning over 30 years.
It's not going to get rewritten in anything else, and the same goes for large amounts of other business software.
The c++ will be staying c++.
I don’t say this out of any affinity for c++(check my other comments for details), rather because for business reasons, the core of this system will always be c++.
In fact we a currently embarking on a multi-million dollar project to upgrade the application to run in the cloud and one of our biggest challenges is finding qualified c++ candidates.
Despite that, due to the complexity and scope of the application and years of business knowledge captured in obscure parts of the code, there is no consideration for it to be rewritten in anything else.
Classical Win32 C APIs are for all practical purposes frozen since Windows XP.
And the answer you practical won't like, when not using COM directly, the advised way from Microsoft is to make use of .NET bindings for the OS APIs, either via C++/CLI, or the new kid in town, C++/WinRT as Windows Runtime Component.
Even if you don't use Windows as desktop, the other desktop contenders, also use COM like APIs on their driver stack, IO Kit, DriverKit, Treble, and XPC/Binder aren't much different from DCE RPC development experience.