thecodedmessage

C++ was grungy in the 90’s, and, well, Rust as it is now is better than C++ as it is now, the comparison that matters now. Rust in 30 years will be better than C++ in 30 years. And safety is a big deal feature, and Rust has it. If it doesn’t have future big deal features, future languages can have it.

I reject the notion that C++‘s “maturity” is a substantial advantage given its unsafety.

Thanks! It’s still not as ergonomic as full first class support, but I did have the situation in my head as worse than it was. This has been fixed :)

I never recommended Go :-) I'd personally rather program C++ than Go, so I can see where you're coming from! That said, C++ is abandonware, switch to a modern language :-) :-)

I'm just spoiled from being able to return and consume a tuple in Rust without writing a standard library function or type name once :-) I'm glad C++ has got it down to one though! Now if only people will start using this instead of out parameters (unlikely...)

You still have to write boilerplate to return them, though :-( But I agree it's better :-) Unfortunately, I'm on C++11 for this project, will be on C++03 for others :-(

Yes, the "C++ is not usable on its own and needs other tools" defence of C++ :-)

What part of "first-class" don't you understand??

ETA: std::variant is one of the least ergonomic user interfaces I've ever seen. std::tuple seems great until you realize that most PLs that support tuples just do "(,)"s for them, in creating, binding, and naming the type. C++'s versions are just unacceptable, and structured bindings only help on the binding side.

First-class support for these is important. There's no reason they should be in the standard library rather than built into the language itself, besides historical mistakes.

Author of the blog post here. I am limited to C++11 for this, and will be limited to C++03 for some related projects. I did say C++11 in that comment, as I am of course aware that C++ has "fixed" that issue, but I'm still entitled to my gripes. I find it odd that someone claimed I was not aware the issue has been fixed in later versions, when I specifically said a version. People seem to be very motivated to assume I'm wrong about C++... because otherwise they'd have to admit that their favorite language has flaws.

In any case, I revised that section to explain how even the "fixed" version in C++14 is still a paper-cut, and make the section hopefully flow a little better.

ETA: I replied to the right comment. I'm agreeing with you :-)

I said "In C++11" because I am aware that it has been fixed later. But I'm stuck in C++11 for platform reasons and so I get to complain about its problems too. But of course, it is because I am aware that this has been fixed -- crappily -- that I qualified it. I'll add more qualifications for you :-)

And I have now addressed structured bindings in the article itself for what they are: a halfway solution, unacceptable to anyone used to real tuples.

No, you cannot use '= default' for the assignment operators if you have custom copy/move constructors. I thought this was clear that this was my complaint in the post. I will make it clearer in the post. IF you customize the constructors, THEN =default will break your code, even though the correct implementation is entirely boilerplate.

And for tuples, you still need to use std::tie or std::make_tuple on the other end.

See, I CAN program C++. I still prefer Rust.

“Some people who can use other systems fine, can’t use my preferred system” is possibly the worst defense of a system. It’s bad. It’s not something to be proud of.

Yeah, but I’m simply not convinced this cliche is that bad.

Can you explain why it’s bad if a central bank is in the hole? Like, what bad practical effects does it have?

> Maybe he wants to avoid the ten million reply guy Rust evangelists out there

Well, he doesn't get to. If he's going to imply that one of the major selling points of Rust over C++ barely matters, he's going to get a response.

Although you did, by your definition, "reply guy" my blog post with your ill-explained and ultimately unjustifiable objection to it.

> If he was, then why didn't he mention it? You seem to know what Stroustrup's inner thoughts are, so tell me, why didn't he mention it?

As I say immediately afterwards, if he wasn't, he should've been. If Stroustrup thinks Rust is irrelevant to this conversation, he's simply mistaken. It's relevant for bringing memory safety into C++'s last remaining niche, after it's been chased out of most domains already.

> Now, let me ask you: do you have an opinion about what Stroustrup wrote or are you just making sure no one says anything bad about [your_favorite_lang].

Let me answer you: Most of my post still works if you replace Rust with Java. That's why I conclude that the time for Stroustrup to start talking about adding memory safety to C++ is 1995, before Rust was even thought of. If you had read and understood my post, you would've realized it has way more to do with what Stroustrup wrote than Rust in particular. Rust didn't invent memory safety, and Rust didn't make C++ behind the times for not pursuing it.

> You seem very upset that I asked such a simple question.

You didn't ask a question. You made an objection. You started out with a false claim that the NSA document didn't mention Rust, and then you implied that since Stroustrup's document didn't mention Rust, it was inappropriate for me to mention Rust. That's absurd, because Rust is extremely relevant to this conversation, for reasons I explain in the post and here. It's also infuriating, because you're holding me to a standard that sounds like it should be reasonable, but in fact isn't -- this ludicrous idea that replies should be limited strictly to the original topics, even if they can explain why a new topic is relevant, as I do with Rust. So I'm explaining why it's not reasonable, so that the casual reader doesn't mistakenly get the impression that you had a good point.

> very tangential discussions

I've explained (1) why Rust is relevant and (2) why my post would be mostly relevant even if Rust didn't exist, so it's not tangential.

> Or, in this case, I suspect to preach to the choir.

I don't see why this is a bad thing, really. Sometimes, the choir wants someone to explain elegantly to them what they already knew, and help them solidify their thought processes.

You can still have rogue references to deleted objects in such a situation, or invalidated iterators, or plenty of other undefined behaviors even using just modern C++ features.

Therefore, what, exactly?

Do you think Stroustrup is not aware of Rust? Do you seriously think he wasn't thinking about Rust when he wrote this? Even if he wasn't, don't you think he should've been? Do you not think the existence of Rust is relevant to the conversation?

Is this discourse bound by some lawyer-like rules where if someone doesn't bring up something that everyone knows is relevant, it's off the table to mention? Should I have filed a form with you asking for permission to bring up a topic not mentioned in the document I was responding to, even though everyone thinking through it with good faith knows it's on topic?

I just don't think this is a remotely justifiable reading.

Ada and Rust aren’t really comparable, and more importantly Ada and C++ aren’t really comparable. The key feature of Rust isn’t that it’s safe — many programming languages are, after all. The key feature of Rust is that it manages to have an explicit safe subset while maintaining C++’s goals of sophisticated zero-cost abstraction.

Squeak implements it with horrible performance, IIRC

I'm happy you're happy, but I don't think that's most people's experience. Perhaps compared to pre-modern C++.

I back it up, I promise. I don't think it's overstated, except in that perhaps "considered harmful" is ... considered so harmful that there's no appropriate use anymore. But C++ move semantics are quite problematic, and I explain why.

Thanks so much! That article was the original (anti-)inspiration for this post. It is so condescending: "Moves are so simple if you pretend you don't understand what they're for and why they're preferable to copies, and also ignore the name."

Thanks for the compliment!

I wanted to go more into pinning, but this post was already extremely long (and many people have already complained about how long it is). So everything you said is very on-point, just covered by "the details are beyond the scope of this blog post." Would you mind putting this extra information as a comment on the article itself, so other readers in the future can have access?

Rust fans might complain that the static code analysis is not built in, and therefore working a "C++ job" will expose you to code that has not been properly statically analyzed, or not with an analyzer up to your personal standards. Large projects can easily sink to the lowest common denominator of usage that the programming language allows.

But in general I think most Rust fans would agree that C++ with static analysis is better than C++ without static analysis.

C++ then still has the move semantics issue of being surprising and confusing, which I think is more than an "at first" issue -- and I think actually most programmers at most projects are relative novices (or outsiders) in the programming language they're working in. If you're rusty in C++, if you're junior, if you're just stepping in from another PL to look at some C++, this is an increase on cognitive load, even if the static analyzer will catch problems.

Author here!

C++ has serious problems. Linus Torvalds agrees. Bryan Cantrill agrees. Many, many experienced systems programmers agree. Rust solves many of the problems with C++, as a systems programming language. That is the scope of my argument.

I am not really sure in the modern software development world what problem dynamic linking of stdlib solves, especially since so much of stdlib would be monomorphized and/or inlined. C++ with any level of templates is far more unfriendly to dynamic linking -- and again, that is the only language of comparison in scope for this article.

Author here!

My "example" is showing an equivalent to what the C++ compiler actually outputs, inlining the `std::string` abstraction, given the input code, which in this context was C++03, and before emplace.

But emplace doesn't save you here! Emplace doesn't save on heap allocations over a `strdup`, if you're emplacing something from a string literal like this.

Doing:

``` vec.emplace_back("here's a string"); ```

Does indeed do an allocation for the string. It has to, because every `std::string` must manage a heap allocation (modulo the small string optimization which is a nitpick). The string literal is in the `text` section of the binary and can't be the backing for the `std::string` object, which must be in read-write memory and on the heap.

So the `strdup` is correct as an equivalent to what the C++ compiler would output with `std::string` inlined for the example code it covered.

Also, the freeing of the empty object with move semantics is NOT always optimized out, not even close. It can't be, not when those calls can cross a library boundary or be arbitrarily wonky.

You write as if C++ has one optimizer. Rust shares an optimizer with one of the most popular C++ compilers. Implying Rust is somehow "behind" C++ on optimizations is just ill-informed.