[neutronicus]

Yes, Rust is making a smart marketing decision by capitalizing on C programmers' antipathy towards C++ (and everyone else's).

I don't know that this is, ipso facto, evidence of anything about C programmers other than that they really hate C++, though.

[eska]

Your view sounds very jaded to me. Maybe Rust is liked more by C programmers because they prefer its approach, rather than C++'s? Calling it a marketing ploy seems without merit to me.

[neutronicus]

I'm a C++ developer who occasionally writes Rust.

The experience of writing new code in one is very, very similar to the experience of writing new code in the other, right down to the compile times. The lifetime analysis in Rust is nice and pretty far ahead of what static analyzers can do in C++, but Rust Generics are a pretty weak approximation to Templates. Rust has better Browser integration, C++ has Qt. One imagines the languages will catch up to one another on these fronts. C++ has Inheritance, Rust settles for Interface Polymorphism (one can reasonably prefer either).

The one really big difference here is actually cultural - the Rust community all agrees on Cargo, and it's a bit happier to compile the world and distribute static binaries, which removes massive headaches for both the developer and the end user while setting the language up for an eventual, Electron-style tragedy of the commons where a user is running like 8 Rust apps with their own copies of the same 14 libraries resident in memory (but that's a good problem to have because it means you've displaced C/C++ as the linguae francae of native app development).

I guess the other really big difference is that there is no legacy Rust code.

I like C++, but I can understand hating it. But if you have written new code in C++17, and hated it ... I suspect you are going to hate writing Rust too. And if you love Rust and hate C++ ... I suspect what you hate is legacy C++ from 2005.

Finally, I was explicitly not concluding anything about C Programmers beyond that they hate C++.

[vvanders]

As someone who built a career in C++ I like that Rust's generics are a poor approximation of templates(and that includes having worked with some of the modern C++ features). I have months of my life I've lost to the increased compile times from Boost on the applications I've worked on.

C++ also makes it way too easy to reach for shared_ptr instead of unique_ptr leading to all sorts of unfortunate things. Rust makes that much harder and RefCell/Rc/Arc push towards design that are "single owner" which I've found scale out much better once you move into programs that are of a significant complexity.

C++ still wins in portability on some platforms but I have a hard time picking it for anything greenfield at this point.

[pjmlp]

Right now Rust eco-system still isn't as mature as C++ in what concerns integration with Java and .NET, and GPGPU programming. The domains I care about.

However with the support of companies like Microsoft, Rust will eventually get there.

By the way BUILD 2020 will have Rust sessions.

[neutronicus]

I would pick C++ for anything to do with high-performance linear algebra. There are a few other domains (desktop GUI, CAD) where I don't trust the Rust library ecosystem.

But, yeah, there are a ton of domains (notably embedded) where I would want Rust.

[qppo]

I agree with most of what you're saying here except for the point on generics versus templates. I wouldn't say generics are an approximation of templates at all, templates are something in between generic programming and macros and that leads to them being hazardous, slow, and generally speaking unergonomic.

Rust's generics allow for some seriously powerful abstractions to be built in a very clean and readable way, although there can be friction with stuff that would be simple with templates in C++ and quite verbose in Rust.

Maybe concepts will change that.

[adev_]

> I wouldn't say generics are an approximation of templates

Template (at their origins) are nothing more than generics, and a pretty clean, powerful and zero cost way of doing generics.

What you name "hazardous, unergonomic" macros style is not the template system itself. It is mainly due to all the 2005-styles SFINAE hacks that have been invented by abusing templates properties.

SFINAE in C++ is nothing natural, it's at best a dangerous trick to have compile time resolution/execution.

Fortunately all of that should die progressively with C++-17 constexpr for the good of humankind.

[neutronicus]

Non-type Template Parameters ("const Generics") are on the short-term road-map for Rust. Small step from there to recursion and compile-time factorial.