I can understand that. The language has been changing so fast that most of the stuff on the Web is outdated or wrong. I just found a place in the official reference manual that's out of sync with the compiler, and sent in a note. (The lambda/closure syntax is still in a state of flux.)
Rust roughly follows C/C++/Java syntax, except that, like Go, it's a "name: type" language. Talking about ownership in code is new, as is the syntax for that. The ownership syntax is a bolt-on, and it shows. The lambda syntax is kind of weird; the designers went for conciseness over clarity. Some of this will take getting used to. The syntax is no worse than C++, and in some areas, better.
The syntax isn't the hard part, anyway. It's living within the ownership restrictions that's hard. It's hard because that's a design issue. There's a Rust port of Doom, and it has far too much unsafe code, because Doom's data structures were not designed with Rust in mind. It's not yet clear how big an issue this will be. The remark that 10% of Servo, the web page renderer, is unsafe code is a bad sign.
I don't have a personal opinion on this yet. I haven't written enough Rust code. I'm writing an RSS feed parser to get a sense of what it's like to deal with a complex tree in Rust. So far, it's going well, with no need for unsafe code.
If Rust can eliminate buffer overflows, dangling pointers, and memory leaks, that's enough to justify using it in place of C/C++.
FWIW, I just looked at the code in the mozilla/servo repository: more than half (1291) of all mentions of 'unsafe' (2150) are inside autogenerated bindings to CEF (Chromium Embedding Framework), which doesn't seem at all like the interesting/relevant part of the application (it's providing an optional "minimal working" browser chrome for the rendering engine). A lot of the other uses are similarly for other FFI tasks, interfacing with libraries like FreeType, HarfBuzz and Spidermonkey. Obviously it would be nice for those libraries to be in Rust and thus avoid the FFI-is-always-unsafe , but the ecosystem is still young and those libraries are seriously non-trivial, Mozilla and the Servo team presumably want to be able to do the interesting parts of their experimentation rather than spending years porting all the low-level libs to Rust first.
For some "success stories", Servo's CSS parser was now pure Rust, and has a single `unsafe` block: https://github.com/servo/rust-cssparser/blob/38877bc0a50a64a... . Similarly, the pure Rust HTML parser written for Servo doesn't have much unsafe (certainly very little compulsory unsafe, most exists in an alternate DOM implementation, or in the C interface the library exposes): https://github.com/servo/html5ever
That said, Rust is definitely not perfect in this regard, three of the major failings with Rust that force Servo to have a unsafe code are insufficient data-parallel libraries, lack of inheritance-like features to allow the DOM to be CPU and memory efficient, and lack of garbage collection hooks in the compiler.
> The ownership syntax is a bolt-on, and it shows.
Could you go into more detail about what you mean by this?
Servo has been under active development for far longer, and sometimes used unsafe code to work around historical issues that no longer require unsafe code. I find the idea of an idiomatic codebase (written today), that is 10% unsafe code (outside of FFI boundaries) to be difficult to imagine.
How does baking the ability to statically determine resource ownership into a language lead to a class of errors? What sort of errors are these?