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.
> 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.