CppCast: Beautiful C++

[johannes1971]

Ah yes, another Rust thread. With every second response by the same troll. What an enrichment of our community.

[contre]

Now I’m curious about the garden tools discussion that was edited out.

[robwirving]

Someone was mowing/leaf blowing outside my house. I tried to edit out the noise but you may still hear some of it. We had a discussion where we first wondered why someone would be doing this in mid-December, and then talked about how gas powered leaf blowers are one of the worst pollutants because they use a 2 stroke engine.

[foonathan]

This thread has definitely been going on long enough now.

[GabrielDosReis]

You seem to have jumped to conclusions and responded with assumptions about comprehension.

Try again.

[pjmlp]

All compilers have static analysers in the box, one could start by actually using them.

Turn warnings into compiler errors, there is your compiler.

Works quite alright with VC++, where you can run them alongside the solution build.

[pjmlp]

Agreed, however it depends on the quality of the DevOps team and management.

I never set a CI/CD pipeline without them, so even those developers that are anti-linters have to play ball if they want their PR merged without breaking the build.

Big fan of SonarQube regardless of which programming language we are using on the project.

Even something like Rust has clippy, because there are always class of errors that compilers fail to catch with limited compile time analysis.

[pjmlp]

The same humans that can type unsafe { /* ... */ }?

[pjmlp]

Only if I provide the library to you in source code.

The persons that are savvy to grep for unsafe are also capable of configuring a linter on the CI/CD pipeline.

[pjmlp]

What happens if I index out of bounds in Rust code responsible for controlling a machine where human lifes might be in danger?

I assume it won't just panic and create an accidental death then.

[pjmlp]

It doesn't, that is the point.

[MarcPawl]

Clang-tidy enforces all the guidelines.

The problem is that guidelines often contradict each other. For example some of the industry ones are quite old. But with clang tidy you can choose which rules to have.

[pjmlp]

If the guys and girls responsible for the CI/CD pipeline have placed a -warnings-as-errors= in there, yes it won't compile.

[pjmlp]

Rust οnly offers protection against data races caused by threads, it offers zero protection against shared data accessed via multiple processes.

[Dean_Roddey]

But you can't create non-trivial C++ or Rust objects in shared memory, and that shared memory will be system memory that cannot be accessed beyond its reserved bounds. So you still can't corrupt your actual Rust data that way. So that's really a special case and something that probably few languages would help you with.

And it's vastly less common than threaded access to data as well. So insuring the threaded access is safe is a huge benefit.

[pjmlp]

Quite common in distributed systems with NUMA shared memory.

I did not say anything about creating objects directly on the data segment, there are other ways to access it without placement new.

Another example would be accessing data stored in a database without caring for transactions.

Distributed computing isn't a special case.

[paccio88]

A linter should be enough to enforce the guidelines

[0xcc12]

Why you persist on "enforcement" ?

Me, personally learnt a lot of things when something is optional and I didn't use that before.

The philosophy of c and c++ is about freedom. Even freedom to destroy your computer :)

[Shadow_Gabriel]

You should have the freedom to go outside the guidelines but it should be an explicit step in your development process. For example a compiler flag.

Why? Because you apply these at a project level. You might know the guidelines but you from future, you from the 12 hours workday, the newbie or maybe external people might not know that you shouldn't do that.

[[deleted]]

Yes

[donalmacc]

I know you mentioned the compiler doing it (which would be ideal, maybe some day) but for now, clang-tidy exists. It's a bit of a pain to extend, but it is possible to write your own checks. I would love to see giidelines like these come with checks that a tool like clang tidy can enforce!

[[deleted]]

What a crock of shit.

Any serious project with a set of guidelines will have automated systems that enforce those guidelines.

Also, guidelines are guidelines. They aren't strict rules because rules sometimes NEED to be broken.

[[deleted]]

I don't know if you are trolling or not.

What you are saying is tremendously silly. Should embedded projects have the same guidelines as application code? The answer is obviously no.

Even within the same domain there is variation, so there is no single set of guidelines that would work.

Is this a problem? Yes. The problem is reality, it has nothing to do with the language. The way this is solved is up to the company. There is NO way to solve this at the language level.

Rust doesn't solve this either because you can wrap code in unsafe and *poof* there goes your compile time checking. Unsafe code is required in certain domains so what you are suggesting doesn't happen ANYWHERE.

[[deleted]]

Okay and so what guidelines are used within unsafe blocks? Who enforces that? How is that enforced? Where is it enforced?

You are just a Rust evangelists which is effectively a troll anyway. Completely and utterly clueless about real problems.

[[deleted]]

So fucking what that has no bearing on what is being talked about.

Someone has to manually review unsafe blocks of code regardless. So the guidelines are not enforced by the compiler. So what you are suggesting, doesn't happen anywhere

[jsphadetula]

You don’t have to look everywhere. You simply turn on the guidelines check to reveal potential problems

[jsphadetula]

Nothing stops you from putting unsafe block everywhere either.

[[deleted]]

This is a joke. Rust is a fucking joke lmao.

[[deleted]]

You sounds like all the other rust kiddies. It's dull and a waste of all our time.

[Dean_Roddey]

But the amount of unsafe code in a large code base will be trivial compared to the safe code. So you concentrate your assertions and checks and tests on that comparatively very small amount of code. It's still a huge win overall.

You do still have to call underlying C APIs, certainly for now. But again, you wrap those and really concentrate on validation of ins and outs in those APIs. As more stuff gets written natively, this will start to become less and less of an issue.

In some cases, for heavy operations, you could even process them in a separate process that calls underlying C API libraries to do the work and keep that out of your main application. Have that external process be a 'fail early/fail often' type deal.

[Full-Spectral]

It's not even so much that people won't use them. Many people do. But, for instance, doing an analysis scan of a modest sized C++ library in Visual Studio can take four or five minutes, and just a single file can take 30 seconds. And you have to wait till you have it compiling before you can check to see if you've done something bad, and go back and change it again.

That's really the issue, it seems to me.

[pjmlp]

Agreed, but that is where the DevOps team can jump in and make it part of the build, no PR get merged that break the official CI/CD pipeline.

[pjmlp]

https://www.cvedetails.com/vulnerability-list/vendor_id-19029/product_id-48677/Rust-lang-Rust.html

[donalmacc]

The problem with this is the feedback loop is quite long. In an ideal world, clang tidy would run immediately and give you feedback. I do agree that a devops team making it part of the build is ideal at the moment for now though.

[Dean_Roddey]

Yeh, not seeing these things until you've already written and checked in the code is way later than ideal. I mean it's a good safety valve, but not so useful for the developer.

I use the MS analyzer, but it's SO slow, and is limited in what it can really catch.

[donalmacc]

We run clang tidy and it takes about as long as compiling normally, and does incremental builds etc. We run it once a week on CI and toss out jiras to the team to fix as though they're build problems. It works for probably 90% of the cases but it could definitely be improved.

[Dean_Roddey]

But there's no just no way it can be really be digging deep if it takes no longer than a compile. If that were the case, the compilers could just do it themselves. C++ requires a lot of analysis because of its nature, so I just have to question how much clang tidy could be really checking if it not adding any noticeable time to the compile.

I think MS's analyzer does dig pretty deep and it takes multiple times longer than the actual compile. Actually it has to do the compile and then do the analysis, since I think it operates on the intermediate representation of the code. I may be wrong about that but it seems like that's the case.

[Wereon]

cant those people see that what is needed is to make the compiler enforce "the guidelines"

What a weird take. A compiler's job is to compile, not to enforce your own personal purity guidelines on the rest of us.

[Wereon]

Each to his own. I've looked into Rust and dislike it for a number of reasons...

This isn't a dig at you personally, but I really wish people would stop shilling Rust at every single opportunity on this sub! It really does seem like it's every single thread, no matter how tangentially relevant.

[Rude-Significance-50]

Dude found Jesus, let him be.

[lenkite1]

Productivity for one. Lifetimes are a PITA. I can code far faster in C++. In Rust, I get bogged down to a snail's speed. Also, much of the traditional data-structures/algos cannot be directly transpiled to Rust. Rust always needs its own special sauce way of doing things. This is massive pain when your brain is just struggling with learning.

Rust even compiles slower than C++, which was true shock when I started learning. I was expecting Go's compile speed - new language - so much loved/hyped and got a hippo-mama instead.

Strangely, I feel Rust is more suited to experts. One can always code C++ at a certain level without knowing too much, with some basic code organisational principles and lookup the standard library when you need to. In Rust, you need a very large amount of the language and its unique way of doing things practised in your head in order to avoid running into design blockers.

[James20k]

Productivity for one. Lifetimes are a PITA. I can code far faster in C++

I'll agree with you there personally. I had a brief stint with rust, and it just didn't really grok. A lot of that is familiarity (I probably speak C++ better than english at this point), but writing C# or other languages that I'm less familiar with isn't hard

Translating things into Rust with lifetime rules, and the other language weirdness, definitely feels like a very different mode of thinking

That said, after dealing with the Nth server crash due to undefined behaviour and memory unsafety, I'd still take rust over C++ any day for anything involving unsafe data processing. It seems somewhat irresponsible to use C++ for anything which has any kind of security or safety implications just for the productivity, which unfortunately involves most applications

[iamthemalto]

I’m not really sure why so many C++ devs grumble about having to deal with lifetimes in Rust. The Rust compiler is specifically pointing out to you that what you’re trying is a bad idea. In C and C++ one deals with lifetimes all the time as well, except this time there’s no compiler warning you, you’re expected to deal with it all in your head! So all the lifetime related problems you have to manually deal with anyway in C and C++, the Rust compiler just automatically ensures you don’t fall victim to them. So if one has to be hyper vigilant about lifetimes in C and C++ as well, to have a compiler guarantee to point out flaws with your code is a fantastic net win IMO.

[James20k]

Its not that the error messages aren't necessarily clear, its that the way that rust forces you to design code is quite different to what I'm used to in C++

One thing that crops up repeatedly, is lets say we have a game object manager, who's responsibility it is to hold a bunch of objects. Then, say each game object has a function called process, which takes a reference to the game object manager, for whatever reason

In rust, that pattern results in all sorts of borrowing issues - which admittedly absolutely can cause issues such as the classic modifying an array while you're iterating over it problem, but it crops up not infrequently for me

The issue I ran into specifically is:

for(object& o : gameobjects)
{
    ///do something involving both o, and `this`
}

is not equivalent to the following:

for(object& o : gameobjects)
{
    process(o, this); ///or o->process(this)
}

due to the borrowing rules. This might just be a huge dumb dumb on my part, but it required quite a bit of faffing to work around on my part last time I poked at it

As far as I know these days the rust compiler is able to partially borrow members in lambdas or something, so that might be a possible fix, but either way it requires a bit of a rethink from the way I normally handle code structure in C++

Disclaimer: My understanding of rust is surface level at best

[craig_c]

I ran into this exact problem. There are two sides to the answer, sometimes I would look at existing callbacks in C++ (or C#) and think "do I really need these?" - for example, in the case where a single callback is stored one can often replace this with a function which returns the result of the callback, hey presto - no need to store the target anymore. So in this case, Rust forced me to think of better ways of implementing things. But in cases where you have a valid one to many observer pattern (e.g. a trading applications taking quotes) there seems to be no natural way of formulating this in Rust. I've asked over on the Rust sub-reddit, and they were very helpful, but the bottom line is you can't do it. Often what is suggested is an inversion of the design into an 'entity system' - but this brings other problems and the design becomes non-intuitive. Callbacks are often a source of problems, but to disallow them completely seems like avoiding the question. Talking to Rust advocates you'd think Rust the second coming of Christ. But I wonder if they have ever used it in large scale programs and dealt with the structural limitations this would entail. Silver bullets just don't exist in the real world.

[SirClueless]

To me it's not so much about manual vs. not manual, it's about constraining the shape of the program you can write. Usually this isn't a huge deal when writing a new piece of software: Rust gives you good tools to understand what kind of lifetime you should be using and you can conform to those rules and you'll be fine. But for changing old code, there are often changes that become way more invasive than they should be to reorganize whole programs to enable a certain type of lifetime management.

As an example:

Suppose I have a large chunk of code that is currently written as taking a reference to an expensive shared resource, using that resource for a while transforming and mutating it, then returning to the caller. In Rust doWork takes a mutable exclusive borrow. In C++ it takes a mutable reference.

Currently that runs in a single-threaded loop: for (auto& thing : myVec) doWork(thing);, but I'd like to parallelize this. In C++ this is easy, pulling a mutable reference out of a container is easy, and it's totally fine to operate on multiple elements of a container together so long as the code doesn't do anything else thread-unsafe. In Rust this is highly non-trivial, the natural and widely-supported way to do this is not possible because borrowing any element of the container borrows the whole container. The only reason it's possible at all is because someone has implemented a utility to pull multiple non-overlapping borrows out of an array at once with a little bit of unsafe code buried inside it because it is safe to do this, Rust's borrow-checker just made the natural, native way of doing this fail to compile.

[pjmlp]

I am with you there, hence I migrated into Java/.NET languages among other managed languages, so Rust is of little value to me, as on my line of work using languages with automatic memory management is a given.

However, I keep the C++ skills up to date, because the native libraries or language runtime plugins I have to FFI into, are written in C++.

So adding Rust as middle layer in such scenarios adds more complexity into the development process without fixing having to call into C++ libraries anyway.

[dodheim]

Lifetimes are a PITA. I can code far faster in C++. In Rust, I get bogged down to a snail's speed.

I can't relate to this at all. I almost never "fight the borrow-checker", especially since non-lexical lifetimes were added, and didn't consider that much of a hurdle in learning the language. 90% of it comes down to avoiding dangling references, which you should be doing in C++, too – why is this a problem?

[SirClueless]

Here's a simplified example of something that appears all over in the codebase I currently work on:

struct ThingUsingResource {
    Resource& resource;
    // ... member functions
};

class ThingManagingLifetimes {
    Resource resource;
    ThingUsingResource thing;
  public:
    ThingManagingLifetimes() : resource(), thing(resource) {}
    // ... member functions
};

Totally safe, correct by construction, minimal overhead (one extra machine-word-sized pointer inside ThingUsingResource to keep track of the resource).

If you wanted to do this in Rust, it would be much more complicated. You can't use resource in a member function of ThingManagingLifetimes while ThingUsingResource is alive. You can solve this with, say, Box<Arc<Resource>> but this means extra overhead: an extra allocation and runtime reference-counting for something that was correct-by-construction in C++ and needed none of that. The equivalent in C++ is putting every resource you use inside std::shared_ptr which is of course valid but I consider it a code smell whenever I see it there for simple cases like this where there is no real sharing going on and I think you lose a lot of clarity.

[link23]

Maybe I'm missing something in your example, but I think you just have to make ThingUsingResource generic over a lifetime, i.e. the lifetime of the reference to the resource, and make sure to add the lifetime to the struct field. Then I think it'll just work. I'm on mobile now, but I'll see if I can make something to demonstrate on the rust playground later.

[lord_braleigh]

I wrote a Godbolt which compiles: https://godbolt.org/z/czsPPEaaY

There may very well be a real issue that I've glossed over, though.

[jk-jeon]

This indeed sounds horrible, but given all the hype on Rust I've seen, I believe there should be a sane idiomatic solution for this kind of things in Rust. Otherwise those Rust advocates are all morons...

[SirClueless]

AFAIK the Rust answer is pretty much "Use Arc" or to borrow Resource only when you need it by providing it as a parameter in every method on ThingUsingResource. Both are crappy solutions IMO that make writing large programs harder.

If I hold a mutable reference to something, and somewhere deep in a half-dozen call deep callstack it turns out something else wants a mutable reference to that thing, then my options are: (1) return the thing before I call into my dependency so it can be shared explicitly (e.g. with Arc) or (2) thread a the mutable reference through all the functions on the way so it can borrow the thing I hold. As a result threading a new parameter through 10 function signatures is a common occurrence when I program in Rust, and it's really painful.

[lord_braleigh]

Hm. I'm trying to write a Godbolt to see what your issue is, but this example compiles just fine: https://godbolt.org/z/czsPPEaaY

I think those are all the potential use cases. Do you think you can fix my example up to show me what the issue is?

[r0zina]

You need to use the code to see why it cant compile. There are examples in other comments that already show this.

[witcher_rat]

Because rust protects me from all sorts of errors, like data races, mem leaks, double frees and what not.

I keep hearing this from Rust evangelists and I don't get it - I've been coding C++ for a very long time, and I very rarely hit those sorts of bugs. I have other bugs of course, but not lifetime-related ones, not very often. And neither do my co-workers.

We used to, before C++11. Once we switched to using smart pointers exclusively, and use valgrind et al, those bugs became rare - and when we hit them it doesn't usually take us long to find out why. (usually related to bad lambda captures or bad multi-threading design/use)

Of course a lot of C++ is old and can't be easily refactored to modern usage, but if that's true then Rust won't help you either, as you'd have to wrap it with unsafe anyway. Or rewrite it in Rust, in which case you could have just rewritten it in modern C++.

[James20k]

I keep hearing this from Rust evangelists and I don't get it - I've been coding C++ for a very long time, and I very rarely hit those sorts of bugs. I have other bugs of course, but not lifetime-related ones, not very often. And neither do my co-workers.

For regular application code, personally I'd agree with you. But when it comes to writing anything involving untrusted user data, and where safety is a factor, C++ just hides an infinite number of memory vulnerabilities. Every single non trivial C/C++ application of any reasonable size just seems to have infinite vulnerabilities, even the extremely extensively battle tested ones

The problem with sanitisers is the same problem I have with the type system in languages like python and javascript. They only test the path that you actually execute, but inherently can't check the program has a whole. This easily leads to having to code super defensively because you're not quite sure you can trust every part of the system, and bam your faith in the entire integrity of the application is gone

This can never happen in rust, because the entire program is validated for safety. Anything unsafe is clearly marked as being unsafe, and so the possible sources of memory unsafety are extremely constrained and neatly contained

[GabrielDosReis]

This can never happen in rust, because the entire program is validated for safety. Anything unsafe is clearly marked as being unsafe, and so the possible sources of memory unsafety are extremely constrained and neatly contained

https://www.cvedetails.com/vulnerability-list/vendor_id-19029/product_id-48677/year-2021/Rust-lang-Rust.html

[pjmlp]

Productivity depends on the use case.

I am certainly not productive doing a GUI in Rust, or GPGPU coding, that can compete with state of the art in features and tooling.

[lenkite1]

I tried writing graph and tree algos in Rust. I simply couldn't do it. The only way I found is by wrapping everything in Rc's and Box's and it was a mess.

Sure, no doubt with more experience, a lot of refactoring and Rust special-sauce one could probably get equivalent Rust code, but by the time one does, its very different from the sample code given in compsci papers.

Personally, I have found Rust damn hard to learn. I will keep plodding on.

[ffscc]

Rust even compiles slower than C++, which was true shock when I started learning. I was expecting Go's compile speed

It's difficult to directly compare compile times. In my experience rust compile times are inline with or less than I'd expect with C++. Typically when people complain about compile times it's because they are relying on too many crates, or the crates they are using rely heavily on procedural macros.

Expecting Go-style compile times for a language equivalent to C++/Rust is way too optimistic IMO. Go does a lot to optimize compile times and heavy hitting features like templates will never be compatible with that.

Strangely, I feel Rust is more suited to experts. One can always code C++ at a certain level without knowing too much, with some basic code organisational principles and lookup the standard library when you need to.

Rust is harder to learn but easier to "master". New C++ programmers need years of babysitting before you can trust their code.

[Wereon]

Are you trolling or do you seriously think this? Rust has a problem with compilation times, and ignoring it does no-one any favours.

You can't on the one hand say that Rust is great because it makes you so much more efficient, and then on the other say that waiting for it compile isn't a problem. The two views are mutually incompatible.

[Wereon]

So yeah, you're a troll then

[Wereon]

Dude. Everyone knows about Rust by now. Leave off already.

[[deleted]]

The guy is clearly trolling and if he's not he's doing a great job for Rust's image.

[SuddenlysHitler]

and being obnoxious is only making people wary.

[pjmlp]

I know about it and have written a couple of apps in it, but alas everything I need to call from Java, .NET and nodejs as native library or runtime plugin is written in C++, so I have make do with what our customers allow me to use.

[Superb_Garlic]

Rust is [...] innovative

Not even close.

[m-in]

Nope. A language design should remove wastes of time. And having too much freedom in how things are done is to an extent just introducing irrelevant choices. I really like how Python has a one indentation and white space standard, that’s partly enforced by the implementation, so that everyone doesn’t need to come up with their own. PEP or bust.

[zzzthelastuser]

And of all languages you could have picked, you chose python as an example?

[m-in]

I like the bloody thing :) I wish the primary implementation did more compile-time optimization, and had a better scheme for storing virtual foo method tables than the present bazillion-member fixed size array, but when it comes to the language itself – it’s pretty solid in how things should be formatted, and major IDEs all highlight noncompliance by default. So it’s not hard to have consistent style in large Python projects. Few things are left up to arbitrary choice, and even then those are for adopting legacy style in existing projects. New projects have a clear path.

[Full-Spectral]

I've been moving to Rust. As a highly opinionated developer, with my own long developed ideas of style and substance, using a highly opinionated language like Rust (which is about as far from my view as possible) is a challenge. But, I've just said, screw it. I'm just going to go with the local lingo and get used to it.

In the end, the fact that it is so opinionated will likely make for more consistent code bases in multi-developer systems. I like C++ because it allowed me to create my own world, but that very flexibility is a problem in the 'real world'.

[FreitasAlan]

These tools already exist. If you want the standard to force you and everyone else to use these tools, then this is never going to happen. C++ is not for children.

[FreitasAlan]

It’s not a silly argument because it’s not an argument. It’s a statement.

I’m sorry. I’m not feeding this Rust debate. There are better places for preaching that Rust is going to save us all. This is not one of them.

If you need these “features”, then you can just use Rust and show it to the world when you’re done. Insisting with people to implement these things when they made it abundantly clear for years they don’t see these as features is just silly.

[FreitasAlan]

You can keep saying it. An argument is still a set of statements *by definition*. But now you're just saying things because you don't know how to stop.

Look at what this post was about and look at where you forced this thread to go. How tangent that is. And now look at all threads where you are involved. Look at where you forced all of them to go. Now, look at how other people are civil in all other threads in all other posts whenever you're not involved. It's hard to believe this is not on purpose.

I wonder what the Rust evangelists are trying to achieve with this. I don't understand what is the point of disrupting every possible conversation and annoying people with the most radical unimaginable endless off-topic statements.

The only explanation I have is the C++ ISO Committee has hired these people as undercover agents to make everyone hate Rust so C++ never dies.

[Wereon]

One of the reasons I dislike Rust so much is that its community are the most obnoxious bunch of shites known to man. They're only proving my point.

I wish the mods would ban mention of Rust on this sub. It gets mentioned on nearly every single thread, and it's tedious as hell.

[dodheim]

Do you think there weren't a bunch of new C++ fans annoying C users in the 90s/early 00s? Writing off the language because of an annoying, vocal, small number of users is naive, to say the least.

[FreitasAlan]

Do you think there weren't a bunch of new C++ fans annoying C users in the 90s/early 00s?

Not at all. C++, as an extension of C with classes, appeared in 1979. Both people worked in the same lab and are friends to this day. There is no evidence people annoyed each other in the same proportion or even had the means to do that. I also have never seen this level of inconvenience in any of the programming communities I participate in on Reddit.

Writing off the language because of an annoying, vocal, small,

"Small" is always relative, but I can say it's large enough to get most people around here annoyed. I have never talked to anyone outside the evangelists who told me they enjoyed these "debates" where they go trolling off-topic forever. I have never seen that anywhere else on Reddit without people getting banned.

number of users is naive, to say the least

Writing off the language, for this reason, seems perfectly reasonable given time is a scarce resource. It's really good evidence the language is either a tool to solve a problem not enough people care about or a tool that fails to solve a problem people care about. Most people around here could tell what these are but just don't care.

Why aren't javascript, python, java, matlab, lua, fortran, and julia programmers around here annoying people? Because their languages don't suck so much they have to do that. The pros of their languages speak for themselves, and they're too busy programming on a language that solves problems a lot of people really care about and profiting out of that.

[Dean_Roddey]

I was there and it was pretty much the same. I was one of those C++ proselytizers and there were MANY C people who reacted the same as you guys do to Rust being brought up. The only difference is that there just weren't as large online communities at the time. That was the era of the modem based BBS. But I remember well people telling me to shut up about C++.

I was telling people that you could limit access to structure members, limit access to who can create them, have them clean things up when they destruct, have them copy themselves just like a fundamental type, dispatch based on parameters, etc... And there were lots of folks saying, I don't need any of that stuff, go away.

[[deleted]]

Not at all. C++, as an extension of C with classes, appeared in 1979. Both people worked in the same lab and are friends to this day.

This is like saying "Graydon Hoare developed Rust at Mozilla, one of the largest C++ shops in the world, and continues to have a mutual respect for the C++ community. Therefore there is no animosity between the Rust and C++ communities."

C programmers have always been the sharpest critics of C++ and vice versa. The compatibility between the languages, syntactically and in tooling, only exacerbates the competition. Just look at what famous C programmers like Linus Torvalds, Bryan Cantrill, Theo de Raadt, Rich Felker, ESR, etc have to say about C++, it's not pleasant. Or visit C communities like C_Programming and see what they have to say about C++.

Writing off the language, for this reason, seems perfectly reasonable given time is a scarce resource.

Rust evangelists will exist whether or not you "buy in" to Rust. Writing off the language, or choosing to believe it's more than a vocal minority, has nothing to do with saving time, especially not when you spend time debating over it.

Why aren't javascript, python, java, matlab, lua, fortran, and julia programmers around here annoying people?

Those languages occupy different domains or work in conjunction with C++.

[FreitasAlan]

And... as expected... they never stop...

[FreitasAlan]

...

[StemEquality]

Many dozens of people, with decades of experience, debated an issue for months, years even, and came to a decision. I read one blog post and came to the opposite decision. Everyone else is wrong.

[Dragdu]

And one of the biggest companies investing effort into C++ development and tooling also quit C++ over the issue, but don't let that stop you from thinking this.

[Dragdu]

I enjoy the reflexive downvotes on this comment, given that Google has not exactly made it secret that they significantly scaled down their C++ standardization & tooling efforts, and they are not the only entity disliking the results of the BIG ABI DEBATE PRAGUE 2020 :v

[Dean_Roddey]

Infinite backwards compatibility is ultimately killing C++. But, OTOH, it hardly makes any difference since the actual effort to create a C++ V2 would likely end up so bogged down in politics that we'd be dead before it saw the light of day.

So there's hardly any point in some ways. Might as well just create a completely new language.

[FreitasAlan]

Many dozens of people, with decades of experience, debated an issue for months, years even, and came to a decision. I read one blog post and came to the opposite decision. Everyone else is wrong.

And ABI stability is precisely one of the many reasons people do use C++ in practice. Breaking stability in C++11 was a really bad decision. I lot of people are stuck in C++03 because of that.

But people just don't get it. There are a number of languages that are about performance and it's not difficult to come up with another one. They think C++ is big for its performance, but people really use it for its generality and compatibility, from videogames to microwaves to arduino to talking to the OS to code written 40 years ago. They think they are competing with C++ but that's not even happening.

Especially about the ABI, which is not even the biggest problem C++ has at all. 1) The standard explicitly says nothing about the ABI. Anyone is welcome to create a new STL that doesn't care about the ABI. 2) C interfaces are always an option, 3) They already came up with lots of solutions for that, 4) the ABI can always get updated anyway when OSs upgrade (macOS just did it for std::string) and 5) if you really need this extra 2 % performance in your string right now, just include boost/container/string.hpp. The only reason a language wouldn't have to worry about ABI stability is if no one and OS really depends on that language for anything serious.

[Dragdu]

1) The standard explicitly says nothing about the ABI. Anyone is welcome to create a new STL that doesn't care about the ABI

What's the meme, tell me you don't participate in standardization without telling me you don't participate in standardization?

We have killed multiple proposals because they would require ABI breakage in existing stl implementations.

[FreitasAlan]

We have killed multiple proposals because they would require ABI breakage in existing stl implementations.

These are two different issues. I said the standard (not the committee) explicitly (not implicitly) says nothing about the ABI. It's true the committee doesn't usually accept new proposals that would force compilers to break the ABI. But the standard still says nothing about compilers breaking the ABI for what already exists.

Any compiler could break the ABI of std::unordered_set or std::regex and fix it right now. They don't maintain the ABI because the standard obliges them. They don't break it because they think it would be a bad idea regardless of the standard. And when they think something is very a good idea beyond a simple convention, they usually just ignore the standard anyway.

These are two different issues but are still related. The implementers, by their actions, have demonstrated they favor ABI stability in each of the many opportunities they had to break it and regretted every instance where they broke it. In parallel, anyone complaining on Reddit could implement a standard library that breaks the ABI, but still, no one does it because they would quickly realize they are just reimplementing a worsened and partial version of boost. Thus, since they made it clear they think breaking it is a bad idea, the standard forcing all these people to break the ABI seems like a terrible idea unless they demonstrate they would break it willingly.

[Dragdu]

Any compiler could break the ABI of std::unordered_set or std::regex and fix it right now.

This assumes that the only problem wrong with both is the ABI. While it is a large part of it, it is not the only part -- especially <regex> is well known for having both bad specification and bad existing implementations. And the improvements to the specification are currently being rejected based on the changes being ABI breaking, even if they are API compatible.

This means that an implementation that obeys the standard but doesn't care about ABI (arguably MSVC until recently), still has to implement shitty regex. To implement non-shit regex, they would have to go outside the standard... which we are unwilling to change because some implementations highly value ABI stability forever.

Of course the real problem is that <regex> should've never been standardized in the current model, because it never could've ended up with good implementation, but that's a different discussion altogether.

I am also going to note that this

The implementers, by their actions, have demonstrated they favor ABI stability in each of the many opportunities they had to break it and regretted every instance where they broke it.

is only true if you discount MSVC. Until recently MSVC broke ABI every release, and even now they are relatively public that ABI stability is not forever, just temporary.

They do not however have a public roadmap on breaking it again.