Lifetime elision seems thoroughly broken or extremely limited in functionality, and now when I'm writing (sometimes seemingly trivial) solutions in Rust I'm spending at least as much time and mental energy explicitly annotating lifetimes as I would be if I was just managing malloc and free in C.
As a result the pain vs. benefit curve doesn't bend nearly as far toward Rust as it theoretically should.
It also could be a programming style thing; I've seen newcomers from C++ often trying to program in the C++ style and having lifetime troubles because the C++ style isn't really amenable to Rust's model. (I feel this might be the issue since you mentioned "sometimes seemingly trivial" -- almost every time someone has said something like that about Rust it's a matter of a programming pattern not translating directly)
Also, really, lifetimes don't do away with the effort required in manual memory management, they just confer it to compile time, so at least you can be sure that your code works and will not break in the future. They're not really a new concept, you think about them anyway in C++, just in a different way.
Most of the cases where I run into this problem and end up feeling like I didn't gain much, if anything, from doing a straight C implementation are situations with deeply nested data structures.
I get that the thinking is that the benefit is that once I've made the compiler stop complaining, my memory management model should at least be sound and safe, and that is a win. Though immediately following that I start to have dream-like fantasies where this entire static analysis stage is simply bolted onto C instead of being a whole new language.
Afterall you can do some pretty impressive stuff with nothing but a pile of preprocessor macros (see Objective C).
If you're using Rust for FFI from functional languages (or any language, really) you need to use a fair amount of unsafe code to get the interface correctly. There's not much benefit for simple things (aside from cases like these: https://gist.github.com/steveklabnik/1a3ec0ca676aaddf766e), but for more complex things it works out pretty nicely.
Your feeling doesn't line up with what has been observed in practice. Empirically, people do not get the memory management right in C. They mess up, again and again and again. In Rust, however, the compiler enforces that you get it right.
> Though immediately following that I start to have dream-like fantasies where this entire static analysis stage is simply bolted onto C instead of being a whole new language.
I don't think it's really possible to bolt Rust's semantics onto C. Too much will break: in particular C code is not written with inherited mutability, which is critical to Rust. You could maybe do something like the proposed lifetime stuff in C++, which still requires lots of annotation, enough to effectively be a whole new language.
Rust has a lot better ergonomics anyway.
> Afterall you can do some pretty impressive stuff with nothing but a pile of preprocessor macros (see Objective C).
Objective-C isn't "a pile of preprocessor macros", and it would be completely impossible to implement the lifetime system using the preprocessor.
I remember thinking when watching the talk that this was a very bad day for Rust as C++ could now do most of what Rust was promising
I think that Rust's system has proven itself to be about as simple and easy to use as you can get in this space. I also think that you cannot just "bolt on" a lifetime system to an existing language that was not designed for it without large amounts of annotation, modification of existing code, and additional learning curve.
OS vendors will happily just add GSL and static analysis driven support to C++, with Rust becoming the language that drove them to do that and that is it.
Microsoft (GSL + static analysis, C++/CX, System C#, .NET Native) and Apple (Swift) are already working on what might be their next systems programming language.
They might lack full Rust like safety, but they are a good enough incremental approach to safety, come with integration with their existing tools and libraries.
Which leaves Rust adoption for systems programming to other OS vendors, e.g. embedded space or open source OSes.
Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.
As to guess whether Rust will put down C++ forever and ever, is another hard question. It will be a matter of community and sadly money... For instance, Apple's already got a much better market share with Swift (look at the job trends) simply because it's Apple. Same goes for JavaScript greatly helped by Google (V8) for their interest (a faster JavaScript engine ==> better usage of Google's web services).
So if you are a CTO or someone who has the responsibility of deciding what language to use for your performance critical software, you already have a large bias toward C++. You may be swayed toward Rust by the fact that Rust is memory safe. However, when someone comes and tells you that with this open source tool for C++ backed by the big names in C++, and developed and supported by Microsoft, and just by using the GSL types you can get most of the benefit of Rust, you will decide that the delta of improvement of Rust over C++ is not worth it.
TLDR: In programming language use pragmatic considerations trump purity. Multibillion dollar companies run on C++. With GSL and static analysis, C++ is "good enough".
Rust is already being integrated into Firefox
> You may be swayed toward Rust by the fact that Rust is memory safe. However, when someone comes and tells you that with this open source tool for C++ backed by the big names in C++, and developed and supported by Microsoft, and just by using the GSL types you can get most of the benefit of Rust, you will decide that the delta of improvement of Rust over C++ is not worth it.
Replace "Rust" with "Ruby on Rails", "C++" with "Java", and "GSL types" with "Spring", and you could make the same statement in 2005. It might even sound plausible. It would also be an incredibly wrong prediction.
> There are already billions of lines of C++ in mission-critical production use.
How many lines of memory-safe C++ are there in production use? The amount of memory-safe Rust code far exceeds that.
Ergonomics and the ecosystem matter. The fact is that the proposed static analysis tool for C++ is very restrictive and complex, from everything I've seen so far, and coupled with the annotation burden equal to that of Rust effectively makes it into a completely different language.
As you say, there's a ton of C++ code out there. However, five things:
1. A _lot_ of that is C++98.
2. These rules are just proposed. There's tons of time.
3. They don't give you as much safety as Rust.
4. Many people have already rejected C++.
5. Langauges don't die.
As for three, while these rules help, and are laudable, they still don't give you data race freedom. In general, they're not intended to be an ironclad safety system, just something to help catch more cases where something went wrong. See Herb's insistence that pointers should be able to dangle in some circumstances, as an example. I saw a comment on Reddit that straddles three and four, here it is: https://www.reddit.com/r/programming/comments/3m6j2c/cppcon_...
> Just follow this set of hundreds of rules (seriously, go read the core
> guidelines), ignore 20 years of material written about C++ before the
> year 2011, use this non-standard third-party library of stuff we
> really like, and you too can have a fraction of Rust's compile safety.
A lot of people have already rejected C++, for various reasons. The details of those reasons are varied, and may be good reasons or bad reasons, but the point is, they've already said nope. A lot of people coming to Rust fit in this category. "I tried C++ one time, but it's too complex." "I can write some basic C++, but I'm not confident my code is correct." "I write Ruby code, C++ looks terrifying, and I hear it's hard never tried it." And so on. Our industry is huge, there are a lot of developers, and not all of them will use a single language even if it's 'better.' That cuts both ways.
And ties into five. I don't think the question "Will Rust kill C++" is well formed. A language that's used as much as C++ is will never die. We'll have C++ code in production for at least my lifetime, I'd bet. Rust doesn't need for C++ to go away. Languages aren't the Highlander, there can (and often are) more than one. I mean, look at Python and Ruby. They're really similar languages from a PLT perspective, but they're both active, healthy, used-by-millions languages, and many of their programmers wouldn't switch to the other. This is totally fine.
If anything, please take my point of view of someone that cannot ever use Rust until the customers say I am allowed to.
On my type of work we only use first class languages, those that are provided as part of whatever platform we are targeting.
This is my point of view of "worse is better".
Many might have rejected C++ or C (e.g. I don't like C at all), but many more are on the same boat as I.
For us system programming means C++ and C, until the IT department or customer allows anything else on our dev machines.
I think in the majority of cases this might turn out to happen.
Swift at least isn't in the same space as Rust. It's a fully garbage-collected language.
> Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.
And Rust has the most memory-safe low-level systems code available today. It also has Cargo and crates.io, which allow that code to be easily reused.
By contrast, existing C++ code isn't safe C++ code. It will have to be ported, often by drastically altering the idioms in use, and that takes a lot of time.
Have you spent any time reading Apple documentation?
https://developer.apple.com/swift/
"Swift is a successor to both the C and Objective-C languages."
Mesa/Cedar at Xerox PARC was also systems programming language with RC.
Going back to my comment "Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.".
<devil advocate mode>
Give me Swift like Playground, Instruments integration, XCode and LLDB integration. Ability to call any Mac API the same way Swift does. Then maybe our customers will request Rust for our iDevices projects.
Give me Visual Studio integration, ability to define WinRT controls like C++/CX, create and debug COM like VC++, mixed mode debugging with .NET. Then maybe our customers will request Rust for our Windows projects.
</devil advocate mode>
Again, I am pretty aware that Rust is way better than half baked solutions like GSL + static analysis, but I have quite a few grey hairs already.
My first C++ compiler was Turbo C++ 1.0 for MS-DOS, remember when it was just released?
I also remember when C had zero presence on home computers.
Which means I was there when Ada, Modula-2, Modula-3, Oberon and derivatives were steam rolled by OS vendors betting the house in C.
As an early C++ adopter, I also carry quite a few flame war scars from being on the C++ side of the fence back on those days (vs C). As I always advocated for the C++ improved safety over what C offers.
> And Rust has the most memory-safe low-level systems code available today.
I agree, but do the OS vendors that sell the SDKs we are allowed to use, also agree or will hide their head on the sand and do another round of "worse is better" with their tools?
> By contrast, existing C++ code isn't safe C++ code. It will have to be ported, often by drastically altering the idioms in use, and that takes a lot of time.
Yes, but the eco-system is already here. Which means most companies will rather endure a slow Python 2 to Python 3 code re-factoring than move to another language.
I really want Rust to succeed and be the language I can use whenever I have to go outside JVM, .NET and mobile worlds.
However I have seen too many nice languages become victim of "worse is better" syndrome.
So sorry if my type of "heads up comment" isn't welcome.
Saying something doesn't automatically make it true... however, I believe it is in this case, but maybe not to the degree the quote/you imply: it seems to me that current Swift may not be the best choice for say, writing the kernel itself, or extremely demanding components like a JS engine/the core of a web-browser.
> Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role
NB. the Rust leadership understands this: it's part of why crates.io was an early investment (and literally an investment: Mozilla put money into it), and why there's a pile of efforts towards improving tooling, including IDE integration.
> So sorry if my type of "heads up comment" isn't welcome.
Well... you do make a comment along these lines on essentially every Rust thread here, so it may be getting a bit repetitive at this point.
I will abstain from such comments from now on, hopefully Rust will succeed where the others failed.
And it's not only about safety: a language that doesn't suffer from the consequences of legacy design choices is just less mental burden, easier to learn and easier to teach.
And by breaking backwards compatibility so heavily, it effectively makes the new safe C++ into a different language.
Their proposal does include more elision than Rust (which actually leads to a loss of expressivity of patterns that arise in complex systems), but they still have plenty of annotations.
> Herb made a point that having too many anotations was a weakness of Rust,
> In fact, Herb made a point that having too many anotations was a weakness of Rust, and that they wanted to not have those annotations.
That's because Herb didn't understand Rust.
> Perhaps you are thinking of Herb's slides where he shows things like _In_reads_(num). Those are not part of GSL.
No, I'm referring to the annotations I saw in the paper: https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...
So if these annotations took the same amount of effort as manually managing malloc() and free(), they'd still be strictly better because they're validated at compile time, no?
Basically, shared ownership is pretty central to many C++ patterns, which means they translate poorly into rust.
If you look at the antipattern example in the "Returning Pointers" section of the Rust book [1], you'll see how you are supposed to handle object creation (the box syntax is the same as Box::new) in a Rustic way
[1] https://doc.rust-lang.org/book/box-syntax-and-patterns.html
Do you have examples? Have you filed bugs?