Good question. As I can see, you need to run “cargo test” separately from “cargo build” at the moment. If you want to run them in the same time, could possibly but them together in a Makefile maybe? But I’m sure there are even better solutions that I don’t know about yet :)

I have been focusing a lot on unit test lately in C for embedded, As you have said, it is very nice to see that unit test cases are treated as the same as the code that you write. Do you know if the rust compiler will execute these tests automatically when a build is made? If the test fails, the build is stopped. Analogous to getting a compile time error.

Makes a lot of sense, thanks for the explanation!

1. Excessively explicit typing is bothersome and doesn’t really do much.

2. Nothing is stopping you from adding explicit type annotations. (see examples of how verbose it looks when you explicitly provide lifetime annotations for everywhere that they’d otherwise be inferred)

3. The Rust compiler will only infer a type in an unambiguous situation.

4. Function signatures must be explicitly typed because they are part of the API and ABI. (Otherwise, you end up with the massively chained/nested C++ type signatures that slow the compilation process and make errors obtuse and difficult to understand… and nobody wants that.)

Brilliant, thanks for the insights, Steve!

Often I feel it would help a lot if I had the CS basics down better as I could appreciate the choices that goes into language design a lot more. (self-taught programmer…). Rust really made me want to dig deeper which is a great feeling. Will be learning to get things less wrong. :)

Will definitely file bugs and send patches whenever I figure out something!

> I might have done something wrong, but even the example code in the
Rust book does not seem to play with doc generation very well.

Please don’t hesitate to file bugs or post on users.rust-lang.org if something isn’t working! Even if it’s just a misunderstanding, it can help us make explanations more clear.

> I kinda see how doing things this way can fin Rust’s model of doing
things, but is it really necessary to create a whole new concept and
different patterns for it?

Yes, it’s important for type checking. You might find this interesting: https://users.rust-lang.org/t/what-s-the-difference-between-functions-with-no-return-value-and-diverging-functions/3874

> Need to import types from the standard library to be able to use some of their features, but some other features work automatically.

It’s not that, it’s about not causing conflicts. If we automatically imported traits, then, for example, if library A defines a trait with a `foo()` function, and so does library B, you couldn’t use them together, as their `foo()`s would conflict. By requiring you to import, you can choose which trait gets used, and in which scope.

Anyway, thanks for the great post!