It seems most Rust programmers are switching over from Python (but C and C++ are next, followed by Java and Javascript, look near the end): https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2...

There is no "right" or "wrong" C++, there's also no single "C++ community". I'd say that C++ isn't even a programming language, it's more like a meta-language to build your own language.

Whether that's good or bad is up for discussion, but (a) it gives a lot of freedom, (b) it invites tinkering, (c) it wastes a massive amount of time when trying to communicate with C++ coders from other confessions, and (c) it makes it hard to integrate C++ libraries into C++ projects.

edit: confession => 'denomination' seems to be the correct English term

> a meta-language to build your own language

All (good) programming languages are like that. In general, any API, any library that you develop is a language. I agree that C++ provides powerful tools of abstraction that make these languages easier to use (compared to what can be accomplished in C or Go, for example).

My feeling has been that C++ has a special degree of complexity beyond most languages. Many terms come up in the "day-to-day" that wouldn't come up in other languages (lvalue/rvalue, move semantics), and so much can be overwritten through operators.

I think the only other language with a similar feel is Scala. It's the programming language equivalent to Magic The Gathering: half the fun is just in the mechanics of it all

> complexity beyond most languages

I think complexity of C++ is merely a (partial) reflection of complexity of programming. For example, move semantics that you have mentioned is not specific to C++, and I find it nice when a language offers an explicit formalism for it.

Just like any other multi-paradigm language.

More like half. A large fraction of the Rust community is folks coming from non-systems languages who saw Rust as a gateway to systems.

But we have both, and most of the folks doing comparisons with C++ do tend to be actual C++ devs (because if you're coming from Python or Ruby and haven't done C++ you really ... can't? compare with C++?). At least within the community folks pretty strongly care about misrepresenting other languages so if stuff is inaccurate it gets called out; and for most "rust vs foo" blog posts I've only rarely seen glaring mistakes a few times. Small mistakes are common but those are common to any kind of post.

I took the comment in the post as a bit of hyperbole and probably referring to subjective bits that Rust+C++ & only-C++ programmers tend to disagree on.

In general most of the vocal Rust folks who talk about C++ talk about C++ because they have lived it.

shrug

It can get more subtle than that too, though. For example, see this recent discussion I had on this topic: https://www.reddit.com/r/programming/comments/72p472/why_did...

That post in particular was a subject of discussion at CppCon for a hot second and is partially why I mentioned the Rust thing. There are other things as well, but I don't want to rake people if it isn't necessary. I pay attention to the Rust subreddit and I see enough misconceptions about C++ and how it works in various comments that it helped reinforce my choice to include that snarky statement. I do understand why so many C++ programmers at CppCon thought that Rust can be dismissed as a fad because of its community's understanding of C++. That said, this sort of parroting about how C++ works and why it is "bad" is everywhere and you can even see it in the comments on this very submission (such as mention of std::variant and implicit conversion to bool. That specific issue is easily remedied but wasn't part of the specification. It's been noted as a defect and will be fixed "soon"?)

I still chuckle when randos make arguments like "C++ can't be parsed with an LALR parser", or "virtual functions are more expensive than function pointers", as if the former is the end of the world, and the latter is a checkmate that will suddenly make my knees week, arms heavy. There's code in my editor, and it's just spaghetti.

> I still chuckle when randos make arguments like "C++ can't be parsed with an LALR parser"

I'm not an expert on parsers but I don't think LALR parser can evaluate constexpr C++ functions which is required for parsing C++.

E.g. in the following code, expression `A<f()>::a * u` will parse either as a variable declaration (int* u) or a multiplication (5 * 5) depending on the value returned by constexpr function f:

template<bool b> class A {};

template<> struct A<true> { typedef int a; };

template<> struct A<false> { static const int a = 5; };

constexpr bool f() { return true; }

const int u = 5;

int main() { A<f()>::a * u; }

I think that the OP point is that it doesn't matter much.

Interesting, thanks. I asked in that thread because I legitimately wanted to know; I very much know that my C++ knowledge is ancient, and that many things are very different now. Always learning!

One cause of this phenomenon is both sides sometimes oversimplifying a complex situation in different directions.

When people talk about "C++", they may mean:

- "C++ as it theoretically could be in when C++20 or so is used pervasively"

- "C++ as it can be when certain C++17 features are used pervasively"

- "C++ as it is often used in practice today"

(and this is still oversimplifying more nuanced realities).

It's very common for people to make observations about "C++" which are wrong on one sense and right in another.

This abrasive comment from the author really put me off from the piece. Doesn't help that I first read berium's reddit post which disagrees [1]. He seems to be involved in build2 which has implemented support for Modules which garners more of my trust in this conversation.

Coming from the C++ world and being fairly knowledgeable about the language (not a full language lawyer but someone people usually turn to) and learning Rust, I find it rare for there to be bad comments from the Rust folks. I don't understand where this is coming from.

Now for my own judgemental comment. I see a trend of people in /r/cpp and other places ignoring the differences (like safety) or misrepresent Rust.

To be clear, I fully accept people having differences in priority (how much safety needs to be compiler-enforced). Its people who don't recognize the difference that I'm bothered by.

Rust is also foreign enough that a trivial glance can be misleading like assuming exceptions are the equivalent of panics because someone got caught up on them having a similar implementation (stack unwinding by default) when in reality, Result is more what people should look at (transport information, ?-operator for unwinding, etc).

[1] https://www.reddit.com/r/cpp/comments/75eqal/millennials_are...

It does not follow. It could be that the subset of C++ programmers that are "typically wrong" about C++ are more likely to use rust.

I think the rest of the article elaborates on why I asked that. If only a subset of the C++ community is "typically wrong", that subset involves quite a lot of people, including those on the standards committee, at CppCon, and on /r/cpp.

> Granted, the Rust community is typically wrong about nearly everything when comparing their language to C++...

Well, where they're right is in having a modest and non-condescending attitude, which is something that C++ pundits should consider adopting.

You're generalizing about a group (C++ pundits) in the same way that the author generalizes about another group (the Rust community).

There are C++ experts who display modesty, just as there are members of the Rust community who display modesty. There is no need to try to retaliate against one person's words by hurling generalized insults against an entire group.