What I can remember immediately:
1. Imports are more complex than in Python, because a module can be just a block in code, not necessarily a separate file/folder. E.g. `pub mod my_module { }` is a module inside another module, so you don't need a folder and `__init__` inside to have inner modules.
Also, `use something` may man an external crate.
`use super::something` means import from upper level of modules tree, but it's not necessarily a folder.
2. I can parse what types my functions require in their signatures, or structs require in their members (but I must have resolved where really those names point at), but there's also type elision -- i.e. you don't need to explicitly write the type of every var, it's deduced from what is assigned, for example `let my_var = some_func(...)` -- will make `my_var` have the return type of some_func. Now I must also keep track of all functions and what they return.
And then, there are generics:
let my_var: Vec = vec![...];
Vec is generic, and in this case it has MyType inside. Well, this may be enough to just register `MyType` on my deps list. But then I may do some more calls:
let my_other_var = my_var.pop().unwrap().my_method();
Here, `pop()` returns `Option`, unwrap returns `MyType`, and then in the end, my_method may return whatever, and I essentially need something like a compiler to figure out what it returns.
This seems big like a little compiler or language server.