Being able to have an idea of the assembly that will be generated from Rust code is certainly a motivating goal (I believe that pcwalton has previously indicated his ability to divine as much), though I personally have no experience with bare assembly so I cannot attest to it myself.
You can certainly guarantee data layout (such is required for C interop, for which Rust has very nice support), though by default Rust will e.g. reorder a struct's fields in order to optimize its representation (taking into account padding and such) unless you explicitly ask it not to.
Rust also tries to favor explicitness where it can. For example, even though many people have requested C#-style properties where `foo.bar = baz` can implicitly call a setter function, Rust has rejected this because the runtime behavior of a function call is too different from the runtime behavior of a field lookup. As another example, anything that looks like `foo.bar()` will always be a method call, and `foo.bar` (without direct parentheses) will always be a field lookup, so if you want to call a function pointer stored in a struct field you need to write `(foo.bar)()`.
There are also places where Rust is more explicit than C++. For example, a C++ function `void bar(int& foo)` can be called like `bar(6)`, but the analogous Rust function `fn bar(foo: &i32)` must be called like `bar(&6)`.
However, Rust also has places where it is less explicit than C++. For example, whereas C++ has both `bar.foo()` for direct method calls and `bar->foo()` for method calls that are invoked through a deref, Rust has only `bar.foo()` which has the capability to dereference `bar` if necessary. So it would be incorrect to say that Rust is ultimately more or less explicit than C++... it just has a different mix of explicit and implicit operations.
As to the rest, Rust does indeed have inline asm, and I hear that Rust produces DWARF debuginfo which allows it to be debugged via gdb (though it has to pretend to be C++ in order to play nicely with existing tooling, which can make it awkward sometimes).
You can certainly guarantee data layout (such is required for C interop, for which Rust has very nice support), though by default Rust will e.g. reorder a struct's fields in order to optimize its representation (taking into account padding and such) unless you explicitly ask it not to.
Rust also tries to favor explicitness where it can. For example, even though many people have requested C#-style properties where `foo.bar = baz` can implicitly call a setter function, Rust has rejected this because the runtime behavior of a function call is too different from the runtime behavior of a field lookup. As another example, anything that looks like `foo.bar()` will always be a method call, and `foo.bar` (without direct parentheses) will always be a field lookup, so if you want to call a function pointer stored in a struct field you need to write `(foo.bar)()`.
There are also places where Rust is more explicit than C++. For example, a C++ function `void bar(int& foo)` can be called like `bar(6)`, but the analogous Rust function `fn bar(foo: &i32)` must be called like `bar(&6)`.
However, Rust also has places where it is less explicit than C++. For example, whereas C++ has both `bar.foo()` for direct method calls and `bar->foo()` for method calls that are invoked through a deref, Rust has only `bar.foo()` which has the capability to dereference `bar` if necessary. So it would be incorrect to say that Rust is ultimately more or less explicit than C++... it just has a different mix of explicit and implicit operations.
As to the rest, Rust does indeed have inline asm, and I hear that Rust produces DWARF debuginfo which allows it to be debugged via gdb (though it has to pretend to be C++ in order to play nicely with existing tooling, which can make it awkward sometimes).