Data point about the new module system learnability and musings about language stability

#41

Just joined this community, I will love to join this tutorials class, I don’t know how far you guys have gone and what are the chances of me joining.

0 Likes

#42

@antzshrek my lectures are available on YouTube (https://www.youtube.com/playlist?list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e), but they are in Russian. If you want to learn Rust, the best way is probably following the Rust Book

0 Likes

#43

Hmm, from reading the whole thread at once, one of the main issues seems to be the following: splitting code accross multiple files implies more namespacing / longer item paths.

Maybe the following “trick” should be noted in the documentation:

  • the single file path/to/list/mod.rs

    //! path/to/list/mod.rs
    
    pub
    struct List {
        // ...
    }
    
    impl<'list> IntoIterator for &'list List {
        type IntoIter = ListIter<'list>;
        // ...
    }
    
    pub
    struct ListIter<'list> {
        list: &'list List,
        // ...
    }
    
    impl<'list> Iterator for ListIter<'list> {
        // ...
    }
    
    impl<'list> ExactSizedIterator for ListIter<'list> {
        // ...
    }
    
  • can be split into two files without hurting ergonomics:

    //! path/to/list/mod.rs
    
    pub use self::iter::*;
    mod iter;
    
    pub
    struct List {
        // ...
    }
    
    impl<'list> IntoIterator for &'list List {
        type IntoIter = ListIter<'list>;
        // ...
    }
    
    //! path/to/list/iter.rs
    use super::*;
    
    pub
    struct ListIter<'list> {
        list: &'list List,
        // ...
    }
    
    impl<'list> Iterator for ListIter<'list> {
        // ...
    }
    
    impl<'list> ExactSizedIterator for ListIter<'list> {
        // ...
    }
    

This way, item paths don’t “grow” when splitting code into multiple files.

3 Likes

#44

Do you have any plans to translate your lectures into English? I watched some of them and really liked them. I think a lot of Rust beginners would appreciate them.

0 Likes

#45

I do have vague plans for this, but no promises!

3 Likes

#46

I’ve talked a bit with students, and looks like the main hurdle is lib.rs/main.rs confusion. That is, in the simple cargo layout bin and lib crates live in the same directory, so it’s unclear when one should mod and when one should use.

I wonder if this particular problem is execebrated on 2018 by the fact that there’s no extern crate anymore, and main depends on lib implicitly (that is, its not specified in Cargo.toml).

The tooling fix here would be to tweak Cargo’s default layout and conventions to make sure that different crates live in disjoint directories.

4 Likes

#47

It might also make sense to have bins and libs in different directories somehow.

0 Likes

#48

src/bin/foo.rs works already, and it’ll pick modules from a different directory.

So for a crate with both bin and lib, that seems like a sensible layout:

src/lib.rs
src/modules_for_lib.rs
src/bin/main.rs
src/bin/modules_for_bin.rs

However, it’d be a bit odd to have cargo new always create src/bin/main.rs by default. For a bin-only project that seems like an unnecessary directory nesting.

0 Likes

#49

I have personally always found that layout confusing (though i do use it) because it is weird that bin needs to import the crate that is in the parent directory.

I would rather something like this:

src/lib.rs                  // or maybe lib/lib.rs?
src/modules_for_lib.rs
bin/foo.rs
bin/modules_for_foo_bin.rs
0 Likes

#50

If we still had mod.rs as common, I’d suggest lib/mod.rs and bin/mod.rs.

As is, this is a mostly pointless post.

I tend to specify all my bin paths explicitly personally anyway, unless it’s just a bin crate.

0 Likes