[howinteresting]

I agree in the abstract, but Rust is a step-function improvement compared to most other mainstream languages. It is hard to go back to writing, say, C or C++ once you have a few years of Rust experience—not because you've lost competence in them but because Rust offloads most of the complexity onto the compiler in a way that's simply not possible with older languages. You really start leaning on the affine types, the compile-time mutability xor aliasing checks, the pervasive checking of thread-safety...

[zozbot234]

> It is hard to go back to writing, say, C or C++ once you have a few years of Rust experience ... You really start leaning on the affine types, the compile-time mutability xor aliasing checks, the pervasive checking of thread-safety...

C++ has semi-official Core Guidelines issued by prominent members of the ISO-WG21 standard committee, that describe how to express these things idiomatically. Of course Rust can actually check these things automatically and achieve something close to actual memory safety, but there are ways to at least make a meaningful effort in C++.

[imron]

The key part is "Rust offloads most of the complexity onto the compiler".

Yes you can make a meaningful effort in C++, but one of the great benefits of Rust is that effort is handled by the compiler instead.

[saagarjha]

The burden isn't all that great, as most good C++ code ends up looking like how you'd write the Rust code anyways.

[jcrites]

New C++ code that your team has written, sure. What about all the libraries that you integrate with, that all have different models for allocating/using/freeing buffers? Or system APIs? (At best for those you can build a wrapper layer, and the wrapper layer is subject to the same errors as C/C++ classically is.)

One of the things that struck me as a major advantage about Java and garbage collected languages is that you can simply combine code from different libraries without worrying about what's freeing the objects, because that's the GC's job. With Rust, the memory management model takes over this responsibility without runtime cost (or minimal cost -- perhaps freeing something from the heap, if you allocated it there, but definitely not GC).

With C++, unless the library that you're using is using the same smart point library as you, from the same language version, then aren't you stuck writing wrappers around the libs you want to use?

Types like std::async seem to have changed in every recent revision of C++ version (11, 17, 20). Can you reliably find multiple open source libraries that you could integrate into a codebase that uses futures and async/await?

(It's been a long time since I've done much C++ professionally. I'm asking skeptically but genuinely.)

[pjmlp]

While true, I don't need to rewrite those libraries and can just use them rigth away, and this is why C++ keeps being my to-go language for native libraries, despite some of its flaws.

I can spend all my development budget on the problem instead sacrificing part of it to building an ecosystem.

[oblio]

Yeah, but that's a losing race. Considering how much investment is happening with Rust right now (when Amazon, Facebook, Google, Microsoft, a ton of smaller companies are investing), Rust will become "good enough™" at some point.

I'd imagine that we're at most 3 years away from it having mature libraries for 99% of tasks you'd want to do as a professional developer.

[imron]

Sure, they end up looking similar, but the point is that with C++ the developer carries the burden of making sure everything is correct and doesn't prevent you or other developers from breaking outside the bounds of what is "good" - either on purpose, or accidentally, e.g. when refactoring.

With Rust, the burden of checking all of that is shifted to the compiler, and that reduces cognitive load for the developer.

[pjmlp]

While Rust is a big help regarding memory corruption errors, you still need to watch out for the remaining 30%.

[imron]

Rust is not a panacea for all bugs, but making memory problems and data races a compile time problem rather than a runtime problem is a significant benefit.

[steveklabnik]

The Core Guidelines are great, but don’t attempt to go as far as Rust.

[pjmlp]

Microsoft and Google are taking care it does.

I would watch the upcoming VC++ static analysis talk regarding its progress.

https://visualstudio.microsoft.com/de/pure-virtual-cpp-event...

[steveklabnik]

I don’t know what specifically you mean by “it does” but if you mean “goes as far as Rust,” that’s simply not true. It’s never even been a goal of the project.

[pjmlp]

Indeed, the goal has been to be as close as possible to Rust, given the constraints of C++ semantics.

Note I mean the work being done by Microsoft and Google on top of Core Guidelines on their syntac analysers, which on Microsoft's case are active by default as background process that validate your code as you type.

It will never be as good as Rust is able to, but in some domains a "worse is better" solution will already be better than nothing, because they aren't going to port their code to something else.

[tffgg]

I have been following such efforts (esp. of MS) in C++ for years - progress is so slow. Feels like a slug that halfs it's speed regularly and thus will never arrive at the finish line

[pjmlp]

Me too, however I am the opinion that I rather having something that improves the status quo than nothing at all, specially because there are millions of C and C++ lines of code that no matter what will never be rewritten.

I will consider Microsoft is fully into Rust when Azure Sphere supports Rust instead of being a C only SDK, despite its security marketing.

https://techcommunity.microsoft.com/t5/internet-of-things/de...

The first step in reducing those 70% is to actually use the tools that exist, but unfortunelly the macho attitute is still quite prevalent.

https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary...

Those that are open to embrace Rust, are most likely already using static analyzers.