| > References and lifetimes allow you to safely return pointers to stack allocated objects. This is explicitly called out as non-idiomatic behavior in the documentation, however. The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee. In fact, in general it's recommended not to use Box, because it complicates human reasoning about the code. And while it gets around a lot of the compiler's restrictions, its akin to writing <language of choice> in Rust, which is frowned upon in any language. Recommending its use so broadly is doing a disservice to people who want to learn Rust. > Only at interfaces where the declaration also serves as documentation. Elsewhere, types can generally be inferred. Except where they can't, and those locations aren't terribly consistent. The Rust designers have publicly announced their preference for explicitness over inference, and the language reflects that. > On the other hand, in rust, you can only return one error. This is not unique to rust, or any language really. You can only throw one exception at a time. You can only set one errno at a time. You can only return one `error` at a time. > macros have to be explicitly imported Except for the built in ones, which are the only ones referenced by the OP. Also, by placing the macro delimiter `!` between the name and the parenthesis, it makes the macro harder to scan for visually. I imagine that any editor will want to set up special rules to highlight these distinctly, and having special highlighting for the ones known to change the program flow would be beneficial. > It exposes a lower-level (not simple) memory model because systems programmers need it. Low level memory is simple: write to, read from, write to referenced, read from referenced. The OS adds one more major operation: get heap memory. Everything else is added by languages or libraries. That said, Rust's restrictions on memory lifetimes results in more simplistic memory related code. When you have to jump through extra hoops to create a pointer which may be used beyond a single scope, and the compiler creates so much friction when you want to do anything with them in that greater scope, people will defer back to simplistic memory code. I'm not certain if this is good or bad; it just is at this point. > Alpha means fewer breaking changes and no "major" breaking changes not stability. Any breaking changes affect stability, affects documentation (Rust's library documentation is behind the actual code as of a week ago), and affect 3rd party libraries. The results of this is that if you're not Mozilla, there are significant barriers to writing Rust code right now, and I would not personally recommend learning or writing Rust right now to anybody. |
Why aren't they consistent? The Rust type inference is generally very good, and the places where you have to annotate are places where any typechecker would force you to annotate, because the types are simply underconstrained (e.g. the return type of Vec::collect or mem::transmute).
> The Rust designers have publicly announced their preference for explicitness over inference, and the language reflects that.
As the original author of the typechecker, I can state that the idea that we intentionally made the type inference less powerful than it could have been is totally false. It's always been as powerful as we could make it, except for interface boundaries (where type annotation is needed because of separate compilation anyway).