Okay, so, yeah, it is possible to [create] ".so" libraries from Rust
code and it's possible to [use] foreign ".so" libraries in Rust
programs.

[create]: https://github.com/rust-lang/rfcs/blob/master/text/1510-cdylib.md
[use]: https://static.rust-lang.org/doc/master/book/ffi.html

That's a good start. It means that Rust can interoperate with the C
world, and it's not very hard to accomplish.

Of course, this has nothing to do with the question about "why static
linking by default?" My only guess is that it was easier for the Rust
devs this way. Or let me put it another way: If there were strong, solid
arguments for statically linking everything, why not make them the
headline? If you go to rust-lang.org, you see a lot of compelling
arguments for Rust (like guaranteed memory safety), but static linking
is not on this list. Not even their FAQ elaborates. The Go FAQ doesn't,
either.

Maybe I don't understand this correctly. Maybe static linking is not the
final goal, but just a temporary solution? Then again, why not mention
*that* in the FAQ?

Am I the only one wondering about this?

My best guess is: We want to introduce a completely new language and
there is no ecosystem yet. We want to speed things up and make it as
easy as possible to adopt the language. Static linking and a custom
package manager can help, because you don't need distributions to play
along. Then, once we're big and successful, we can urge distributions to
include our stuff and we can then switch to dynamic linking by default.