Yes, but is it more readable too? The obfuscated C contest also tends to produce a lot of dense/terse code, but you probably wouldn't want to use that in a production system...
Of course, you can write hard to read code. But that's not typically what comes out of a process of writing production software.
That's not to say that someone with no experience will fully understand the ownership transfer & borrowing that's happening, but that's just stuff you need to do for the compiler. Reading code that already compiles, you can mostly ignore that and focus on the program logic.
Especially for someone unfamiliar with rust, it can be hard to really know why someone is using self, &self, or &mut self. Yet the code reads the same.
That's the funny thing about rust.
v1, ok1 := <-c1
Not sure what is difference between := and = and what is that arrow. But if I'm going to do something with the language - I guess it will be easy to find out. Like with Rust.
The major exception to this are cases where authors use macros to invent their own DSL inside Rust code. This sort of thing seems common in the Servo codebase, amomg others. It reminds me of C macros or Python metaprogramming magic, both of which directly led to some incredibly difficult past debugging experiences.
The density comes from being able to share common functionality behind generic interfaces, so I don’t have to reinvent the wheel for every new project.
I find that most projects I make look the same internally, unless I start pulling some “clever” optimizations like custom allocators or self-referential structs.