Long time C++ dev here(~15 years) currently loving Rust. Someone can probably put together a more eloquent comment however here's my top marks.

1. No memory corruptions/null pointers. Legit holds up to the promises here.

2. The path of least resistance is single-ownership which is far and away the best way I've seen to structure C/C++ applications.

3. Cargo: Pure awesome. Simply one of the best dependency management/build tools I've used.

4. Dead simple x-platform support. Windows, Linux, all just works. Heck I just built an android arm-eabi target yesterday on windows with no NDK/etc.

5. Tagged unions, pattern matching. The best effing iterator class I've seen bar none. Once you've used these you don't want to go back.

6. Great built-in unit testing support(combines with Cargo above).

7. Amazing community, no ego and tons of people happy to help.

I still work regularly on C++0x11 codebases but any greenfield stuff I've moved over to Rust fulltime.

I still like C++ but it's so much more painful to use. Heck just earlier today I got bit by <locale> not compiling on OSX due to some obscure compiler differences that worked on MSVC and GCC. There's certainly good improvements coming to C++ but they have to support so much legacy code that I don't think they could ever make the large breaking changes that Rust has to produce a better experience.

Wrong place to ask the question. HN has a high proportion of people with an unusual interest in trying out programming languages and I would say the average visitor doesn't particularly like C++.

From my point of view, Rust doesn't offer any benefits that would justify a switch. I would lose a lot of experience, libraries, a mature stable platform and job opportunities in exchange for more memory safety - something that's not a particularly pressing issue for me.

Furthermore, I think many developers obsess about languages and keep searching for a perfect language that doesn't exist and even if it did wouldn't have a big impact on productivity and the business anyway. The major challenges in organisations are of a social or process nature.

They're also biased in a surprising way by social factors such as who created a PL or the community. Meanwhile PHP, Java, C++ and C# and C make the world go round.

Key questions for me when evaluating whether to learn Rust (or any language):

* can I get a good job programming in this? Without moving to another country or continent.

* is my industry showing interest in it?

* is any industry showing interest?

The answer to all these questions seems to be "no".

I find this comparison much easier than comparing C and Rust. C has an extensive and still unparalleled set of libraries available using the C calling conventions; both C++ and Rust can call those libraries but often want a translation layer that adapts to the conventions of the language. C++ and Rust both have extensive libraries of their own; while C++ has been around longer, you'll still often find yourself needing to use a C library because a native C++ library doesn't exist. (It doesn't help that C++ has gone through several ABI changes, and still doesn't reliably have a cross-compiler compatible ABI the way C does; even clang++ and g++ have had various incompatibilities, and still prefer separate C++ standard libraries. C remains the reliable ABI for libraries.)

While I'm impressed with the changes in modern C++11/14/17, it has both the feature and problem of still including classic C and C++. There's a reasonable subset of C++ to program in, but nobody can quite agree on what that is, and a codebase can't easily enforce that. And C++ is still a very large language, with quite a bit of surface area in the language itself; I prefer a smaller language with a large library ecosystem.

Rust is still quite young. It's incredibly fun to program in, has the most welcoming community I've ever seen, and can help you write safe, expressive, high-performance code. (Tip: check out the "rayon" crate for incredibly easy parallelism.) It has an extensive library ecosystem, and a robust FFI to call (or be called by) C code. However, depending on what you're doing and and how many boundaries you're pushing, you may find some corners of the language still under active development; for instance, if you want to embed some Rust code into a broader build system that builds various other components under other languages, support for that just went into Cargo.

If you're writing pure Rust code, or Rust code that calls out to C, you should find the language and ecosystem ready now. If you're trying to embed Rust into an existing project, expect to play with various experimental bits for a while.

This is all personal opinion so take it with a grain of salt.

I think Rust could do some serious C++ competition if it could dethrone C++ from some platform or have a worthy alternative.

That is I think Rust really needs a killer app/platform/problem similar to how Swift has Apple devices and DevOps now have Go.

If Rust could get into a gaming platform or have a really good gaming library like Unity it could have a good starting point to move over mind share.

Alternatively I think Rust could compete heavily with Go since the whole microservices space is still sort of up for grabs (or atleast is so massive that there is plenty of pie to be had).

Rust's current niche (ie users) is language aficionados which historically hasn't been a good niche (ie Haskell) for language propagation. That is I think Rust could get more popular if it can get heavily used by a set of niche users at first.

Besides mircoservices and games an interesting niche might be Arduino and IOT [1]. That might be a good niche/platform to dethrone C++.

[1]: http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-u...

Rust has been pretty critical to me for getting my work up and running with minimal debugging (I'm in CS grad school, working on deep learning and optimization). I'm super productive programming in Rust, which is also generally a pleasure to write in.

Just last week I had to land a pretty major refactoring (swapping out a single wrapper type for a differentiable "operator" with an implicit operator graph instead). It basically just worked out of the box as soon as I got it to compile. Definitely something to be said for working _with_ the compiler and its messages on moving, borrowing, mutability etc. (Incidentally, if I had to program exclusively in C++11/14, thanks to Rust I'd have become much better at programming in C++.)

I am/was a embedded dev, been using C/C++ since ... more than 15 years. I do C++/Go at $dayjob and I'm in love with Rust.

I've written quite a bit of comments before on Rust, since it's not the first time someone asks similar question. You can read my past comments: https://news.ycombinator.com/threads?id=dpc_pw

Just to sum up, IMO: Rust blows C++ out of the water on almost everything. It's not established enough so there are almost no jobs, and there's a learning curve, lack of tools, slow compilation, business reasons, etc. so you can't just blindly use Rust over C++, but when you can and have time to learn: go for it. The existing tooling is amazing, community is awesome, you will learn really interesting stuff, save time on debugging.

As for C++17 features... I don't really care anymore. C++ is death by thousands little cuts (undefined behavior is my "favorite") it's not going to change much anyway.

My favourite languages are from the Wirth and ML family of languages, so I really like Rust.

On my daily work I get to use JVM, .NET and C++.

Although my C++ usage is restricted to giving a little help to JVM or .NET applications, if at all required, which happens very seldom.

Here is where I still see Rust lacking, due to the language being young.

On those platforms the vendor's tooling supports mixed debugging, out of box integration with their platform libraries and a few other goodies.

For example, for UWP applications Rust tooling is still catching up with C++/CX and C++/WinRT.

Modern C++ does feel like a rejuvenated language, but the problem is that you require a team that is willing, or able, to force it across their code.

Otherwise you just get a mix of C++98, C++03, C++11, C++14, C++17, depending on which library you are looking at. Not to mention having to get your head around meta-programming tricks like SFINAE, as workaround for many of the C++17 features.

So although Modern C++ feels good, there is the question when one takes a C++ at random company X, how much they are allowed to actually use from it.

So I think a reboot into new systems programming languages is required, and Rust is one of the possible candidates.

Which will surely get its place.

> But then there is the idea of ignoring legacy C++ and treating Modern C++ as a new language altogether.

There is no "ignoring legacy C++", when you will have to deal with this or that library written 10/15 years ago. C++ is a language where you can't just ignore some parts of it just because they are inconvenient.

As for C++ vs Rust, Rust is memory safe, C++ is not and will never be despite all the bells and whistles it gets.

I have a big C++ legacy code, and it gives me a lot of headhaches. I'm using Rust in some small projects and it's great, no problens with null pointers :). I think a great feature of Rust is that it is easy to use inside C/C++ projects, so u can upgrade your current legacy code without rewrite it :)

Rust is promising but C++ is here to stay.

If you have a legacy C++ code base, it is much easier to sell that you are just upgrading the compiler to get new language features, that you are rewriting everything from scratch.

Now we'll have to see in the next few years if, for new projects, Rust is chosen over C++ wherever it was used traditionally and in which proportion.

I have a large existing C++ codebase but haven't worked in Rust yet. But from what I've seen, Rust looks like a very well designed language that has the low-level and performance aspects of C++, with similar flexibility. IMO the killer feature is the borrowing mechanism which provides provably-safe memory access, eliminating whole classes of memory/security bugs, with minimal performance impact. I don't think C++ will ever expand to encompass that. I haven't got much experience with the Rust toolchain but I think that's a strong reason to seriously consider Rust for any new projects.

Hope I don't get burned for saying it, but lack of real IDE support in rust is pretty annoying. With tools like racer you can still be productive, but things like rename refactoring or searching for uses of functions are things I miss most from languages like Java or go, which have good support.

There's been some talk for a long time of a rust oracle for code indexing (to support ide use), but there hasn't been much progress (or interest?).

Features and libraries aside, Rust (compiler and language) has 6-week release schedule, open and well-working update process and 0 decades of backward compatibility to satisfy. I don't see C++ improving on that anytime soon.

C is still significantly faster than Rust which follows that C++ is too. So unless Rust is able to produce binaries on all major platforms that are as fast as C++, people who need to squeeze out as much performance as possible are not going to drop the language.

They are both great languages but rust is clearly the one that experts in both generally prefer. I have some friends who make some strange arguments for c++ but I continue to be interested why people don't want to make the switch. That being said LEGACY