I think it’s debatable whether RAII should be called “memory management”. Whether dealing with Rust or modern C++, you don’t need to “manage” the memory beyond specifying a container that will determine its lifecycle behavior, and then you just let it drop.

You could certainly choose to manage it more granularly than that in Rust or C++, but in the vast majority of cases that would be considered bad practice.

That’s a qualitatively different user experience than C or pre-2011 boostless C++ where you actually need to explicitly delete all your heap allocations and manually keep track of which pointers are still valid. Lumping both under “memory management” makes the term so broad that it almost loses its significance.

There are several ways to achieve an effect equivalent to operator overloading in Rust, depending on exactly how you want the overloading to work.

The most common is

fn do_something(arg: impl Into<Args>) {
    ...
}

This lets you pass in anything into the function that can be converted into the Args type. If you define the Args type yourself then you can also define any conversion that you want, and you can make any construction method you want for it. It’s a small touch more explicit than C++'s operator overloading, but I think it pays off overall because you know exactly what function implementation all different choices of arguments will be funneling into.

I’ll admit there’s one thing from C++ that I frequently wish were available in Rust: specialization. Generics in Rust aren’t exactly the same as templates in C++ but they’re close enough that the concept of specialization could apply to traits and generics. There is ongoing work to bring specialization into the language, but it’s taking a long time, and one of my projects in particular would seriously benefit from them being available.

Still, Rust will have specialization support long before C++ has caught up to even a quarter of the benefits that Rust has over it.

Even with modern C++ it’s loaded with seg fault and undefined behavior footguns.

The times when C++ feels more ergonomic than Rust are the times when you’re writing unsafe code and there’s undefined behavior lurking in there, waiting to ambush you once you’ve sent it to production. Code that is 100% guaranteed safe is always, and I really want to emphasize this: always more ergonomic to write in Rust than it is to write in C++.

Show me any case where C++ code seems more ergonomic than its Rust equivalent, and I will always be able to show you how either the C++ code has a bug hiding in it or how the Rust code can be revised with syntactic sugar to be more ergonomic than the C++.

C++ was far and away my favorite language (I used it professionally for 10 years and was always excitedly keeping up with new ISO developments), until I learned the basics of Rust…

Now it’s my firm belief that the world will become a better place when C++ stops existing. C++ just has no positive role to play in a world where Rust exists at the level of maturity that it already has.

Whatever they might try to do to C++ to make it less intolerable will be in vain until they’re ready to break backwards compatibility. And once they’re willing to break backwards compatibility to legitimately improve the language, they’re just going to end up with a messy knock off of Rust.

I don’t agree with the previous poster. There’s nothing wrong with diving in and figuring things out as you go, especially if that’s a way that you commonly like to learn. Everyone has different learning styles, and Rust can fit all those styles.

The main thing to understand is you shouldn’t let compilation errors discourage you. You will get a lot of compilation errors. And I mean A LOT. That’s okay, it’s normal, and it doesn’t mean you’re dumb or that Rust is an excessively difficult language. It generally just means that there’s some new piece of the language for you to learn before you can take your next step.

When you run into compilation errors, just read the error message carefully and see if you can understand what the problem is. Often the error itself will tell you how to fix it, but you should take the opportunity to understand why the fix is necessary. In every case there’s a reason that the language is putting limitations on what you’re doing. It’s to protect you from bad habits that other languages used to let you get away with. So understand what’s bad about what you were doing and you’ll rapidly grow as a developer.

If you can’t figure out what’s wrong from the compilation error alone, that’s when it makes sense to turn to the book. The error messages will generally include a reference code which you can use to get more details on the nature of the error. Googling that will lead you to online discussions and maybe entries in the Rust book. Otherwise there isn’t a real need to read through the book from front to back unless that’s a way you like to learn.

I’m not trying to shill for Google but I really think it would be a mistake to break up Google without breaking up Microsoft simultaneously if not first. If they actually manage to crack open Google’s search and browser monopoly, who do they really think is going to start filling in that void? Local mom and pop search engines…? No it’s primarily going to be Microsoft with Bing and Edge, and I’m absolutely certain that whatever people don’t like about Google having its monopolies is going to be orders of magnitude worse if Microsoft gains ground there.

It makes total sense that new C++ will contain a higher percentage of bugs than old C++, but after being an almost full time Rust dev for the last two years, you will not convince me that new Rust code has more bugs than old C++ code.

So far I have yet to come across a bug in any of my Rust code that made it into production. All issue reports from users are still related to the C++ code base that we haven’t managed to fully divorce from.

The only advantage to C++ interop is that managers want to see new code get deployed immediately and continuously. They don’t want to wait until the corporation’s billions (literally) of lines of code are all rewritten in a new language before they start to see the benefits of that transition.

I’m not convinced he really believes that OpenAI is going to roll out AGI in the next ten years, but I’m completely sure he’s determined that it’s a good marketing strategy to make people believe that he believes it.

OP really needs to heed this advice. Modifying things in the cache will cause breakages that will confuse the hell out of you.

Speaking as an annoying Rust user, you’re being bigoted. I’m annoying, but the vast majority of Rust users are normal people who you wouldn’t even know are using Rust.

Don’t lump all the others in with me, they don’t deserve that.

Best practice when using .unwrap() in production code is to put a line of documentation immediately above the use of .unwrap() that describes the safety invariants which allow the unwrap to be safe.

Since code churn could eventually cause those safety invariants to be violated, I think it’s not a bad thing for a blunt audit of .unwrap() to bring your attention to those cases and prompt to reevaluate if the invariants are still satisfied.

But only if pattern matching were included, otherwise they would be as unpleasant as C++'s std::variant.

This makes a lot of sense, but the functions were Rust bindings for plain C functions, they weren’t function pointers. Granted I could have put pointers to the function bindings into fields in a struct and stored that struct in the mutex, but the ability to anyhow call the bindings would still exist.

It’s a massive win, and I would question the credibility of any systems programmer that doesn’t recognize that as soon as they understand the wrapper arrangement. I would have to assume that such people are going around making egregious errors in how they’re using mutexes in their C-like code, and are the reason Rust is such an important language to roll out everywhere.

The only time I’ve ever needed a Mutex<()> so far with Rust is when I had to interop with a C library which itself was not thread safe (unprotected use of global variables), so I needed to lock the placeholder mutex each time I called one of the C functions.

Originally, a qipao was supposed to be a loose-fitting gown

Source for this? From living in Asia (not in China, but in a predominantly Chinese community), I’ve only seen qipao be form fitting, never loose. Even seeing older pictures of women in qipao, they’re always form fitting. And more often than not, women seem to use them to intentionally highlight their figure.

Chinese communities tend to have a strong conservative bend, but that doesn’t mean they’re puritanical when it comes to sexuality, especially the sexually suggestive.

I think the point is that Republicans detest the idea of being weird no matter what, so they would rage at the suggestion of being a good weird anyway. To them “good weird” is an oxymoron, even though they are actually very weird and not in any kind of good way.

Rust makes sense though.

Yeah the only way it would be that high is if it lumps C and C++ together. But at that point it may be an underestimate.

A better language wouldn’t have any need to use POSIX signals in this way.

I do think that specific point is catering too much to sloppy get-it-done-fast-and-don’t-think developers. It’s true that they are Rust’s most untapped demographic, and the language won’t reach the pinnacle of mainstream usage without getting buy-in from that group, but I really think they’ll be won over eventually by everything else the language and ecosystem offers, and .unwrap() won’t be such an unreasonable price for them to pay in the long run.