I can't speak to everyone's use case, but for ours memory safety is extremely important. C++ is not safe, and we still see tons of memory safety issues, many security-sensitive, in practice, despite using modern C++ for all new code.
Even if safety isn't as important to you, there are other reasons you might be interested in Rust: a module system, pattern matching, a standard library which offers better performance than STL for many tasks, ADTs, concepts, a package manager, etc.
They probably think they aren't, but by definition, we are not smart enough to immediately understand the bugs we write. Otherwise we wouldn't write them.
But hey, it's not like a programmer who overestimates his own skills is a new thing.
What are concepts in this context? It is hard to google.
I've pinged #rust, I'll see if I can get someone who knows more to answer here.
> I think the only big difference is that some errors in Rust are happening at compile time.
This is true in these examples, except maybe the enforcement of not using a pointer after you've sent it to a task.
That said, there are other examples, like iterator invalidation, where Rust is completely memory safe, unlike C++. Furthermore, Rust has significantly less undefined behavior and odd edge cases. These are in C++ for good reason, but they're still there.
> with some extra static checking and good guidelines can go a long way.
They can go a long way, and that may be enough for you. Big applications continue to have security issues due to problems that Rust would prevent, though: in the last Pwn2Own, all of Firefox's bugs would not have been possible in Rust, for example.
I ask because the largest test case for Rust, Servo, is a cross-platform application, and I'm always looking to improve our marketing.
Having said that, immature libraries are to be expected at this point, and I do think Rust is very well positioned to have really good ones for this use case in the short to medium term.
This is absolutely true, but that's a different concern than "It would seem that neither Rust nor Go serve this area and probably do not intend to do it either," which is what I'm curious about.
One of the open questions with GUI toolkit stuff is that Rust does not have named parameters, but Qt, for example, uses them heavily.
To give you some background about the kind of apps I was referring to - I am right now working on a UI-driven app that will be deployed to Android and on the desktop. I am using C++, Qt and platform code where necessary.
All of those things are being built yet, so we don't have much to link to. There are a few work-in-progress things, for example, the postgres adapter is coming along, and rust-graphics for graphical primitives. As we get closer to release, and as they mature, we'll feature them more.
> Will the cross-platform components from Servo be included in the Rust standard library?
As we already have a package manager, I think Rust will tend to have a smaller standard library, and encourage its use more. We'll see though.
> am right now working on a UI-driven app that will be deployed to Android and on the desktop.
We support Windows, Mac, and Linux as first-class platforms, and every pull request (and additions are all through pull requests) is tested on android. iOS coming soon.
This doesn't seem very performance-critical. I doubt the best tool for the job is C++/Rust/C.
For the number add I used a unique_ptr (although returning by value would be better in every way).
For the shared state I used async with a lamba that calls transform and returns the modified vector through a future. This doesn't execute in parallel for each for loop though. I think something like Arc can be coded in C++ too - template wrapper that returns a RAII lock whick unlocks on scope end.
I think the only big difference is that some errors in Rust are happening at compile time. In the first case the original buggy code was triggering only a warning in C++.
Right now the extra compile-safety of Rust is IMO not worth giving up the other benefits of C++, especially now that C++11 with some extra static checking and good guidelines can go a long way.