3 ms·

Well there it is. Rust is difficult not because it's inherently difficult but because it's not the spitting image of the languages you've learned and you're no

Well there it is. Rust is difficult not because it's inherently difficult but because it's not the spitting image of the languages you've learned and you're not interested learning (which is totally fine). Things like putting dependencies (instead of program source) in 'modules' seem intuitive not because they're inherently intuitive or common but because you've taken the time to learn Python. IMO ripgrep is a poor example of project layout both because it does "non-standard" things and because it encompasses more than the C-based grep you're comparing it to. A simple project will almost always have its source in a directory named "src", and a project with multiple subprojects (like ripgrep) will typically not shove them into a "crates" directory. Compared to GNU grep, the ripgrep project serves as the repository for a bunch of libraries as well as the ripgrep binary. So there's already a lot more moving parts than the name "ripgrep" might otherwise suggest. I don't know Java, but I can read the Falstad circuit simulator source. If you can read Java, I'm surprised impl blocks threw you for a loop as the first comparison that comes to mind is that with Java interfaces. A quick look at the Falstead simulator suggests it's using a pretty small subset of the Java language (e.g. no generics, interfaces, or exceptions) which would certainly make it seem a lot like C. Not all Java is like that. & and *? Akin to reference and dereference in C, and given that you can overload both the comparison to C++ seems pretty apt. In any case, for more direct explanations the API reference is a better place to look. Two short sentences explain what unwrap and explain do, and what the differences are.

steveklabnik 3y ago
> project with multiple subprojects (like ripgrep) will typically not shove them into a "crates" directory. This is not unique to ripgrep; for example, that's matklad's general recommendation https://matklad.github.io/2021/08/22/large-rust-workspaces.html https://matklad.github.io/2021/08/22/large-rust-workspaces.h...
- inferiorhuman 3y ago
  Oh interesting, I'd never seen that before. However I'm not a monorepo kinda guy and to me the ripgrep repo already looks way too busy. By the time you've enough crates to shove them in a 'crates' directory I think it's worth splitting them up into different repos.
  - steveklabnik 3y ago
    Cargo is quite bad at true monorepos, so in some sense I agree, but I think there’s often a sweet spot between the two where this makes sense. Some projects are just inherently larger, and breaking them down helps, and spreading the repos out hurts. Just depends.
  - burntsushi 3y ago
    Blech, no. That would make the maintenance burden of dealing with those crates even worse than it already is. And just imagine having issues spread out all across different repos. Oh my goodness. It would be absolute madness. I have split out some crates that obviously stand-alone. The `termcolor` crate was born inside of ripgrep but now it's in its own repository. The `ignore` is another candidate for splitting out because it has broad utility, but it needs a lot of work before it's something that can standalone as its own project IMO. But most of the rest of the crates, i.e., grep-{matcher,searcher,printer,regex,pcre2} are essentially what ripgrep is. Those will never get split out. If I did, the ripgrep repo wouldn't actually contain the most interesting parts of ripgrep! Not good. With all that said, I am a monorepo guy. Not for ideological reasons. For practical reasons. I also maintain dozens of crates, most of which are in their own repositories. The only reason I do a different repository for each because that's what the custom is and it makes collaborating with others easier. If the code was just for me, it would all be in one big mono-repo. No question. It would be A LOT less work.
    - inferiorhuman 3y ago
      With all that said, I am a monorepo guy. Not for ideological reasons. For practical reasons. Yep. It's a balance. The big problem I have with large(r) repos is that everything git related is just slower and takes way more space. I've got some git prompt magic (using gitoxide of course) and it just drags with the rust repo. At one point I wanted to make some changes to a man page in FreeBSD. Sure, it's neat that there's thirty years of history. But it's thirty years of everything's history. Shallow cloning made it a bit more bearable, but the UX for trying to grab just a directory or two from a repo is still petty gnarly. But it's all just emacs vs vi all over again (and I've settled on helix and sublime anyhow).

steveklabnik 3y ago

> project with multiple subprojects (like ripgrep) will typically not shove them into a "crates" directory. This is not unique to ripgrep; for example, that's matklad's general recommendation https://matklad.github.io/2021/08/22/large-rust-workspaces.html https://matklad.github.io/2021/08/22/large-rust-workspaces.h...

inferiorhuman 3y ago
Oh interesting, I'd never seen that before. However I'm not a monorepo kinda guy and to me the ripgrep repo already looks way too busy. By the time you've enough crates to shove them in a 'crates' directory I think it's worth splitting them up into different repos.
- steveklabnik 3y ago
  Cargo is quite bad at true monorepos, so in some sense I agree, but I think there’s often a sweet spot between the two where this makes sense. Some projects are just inherently larger, and breaking them down helps, and spreading the repos out hurts. Just depends.
- burntsushi 3y ago
  Blech, no. That would make the maintenance burden of dealing with those crates even worse than it already is. And just imagine having issues spread out all across different repos. Oh my goodness. It would be absolute madness. I have split out some crates that obviously stand-alone. The `termcolor` crate was born inside of ripgrep but now it's in its own repository. The `ignore` is another candidate for splitting out because it has broad utility, but it needs a lot of work before it's something that can standalone as its own project IMO. But most of the rest of the crates, i.e., grep-{matcher,searcher,printer,regex,pcre2} are essentially what ripgrep is. Those will never get split out. If I did, the ripgrep repo wouldn't actually contain the most interesting parts of ripgrep! Not good. With all that said, I am a monorepo guy. Not for ideological reasons. For practical reasons. I also maintain dozens of crates, most of which are in their own repositories. The only reason I do a different repository for each because that's what the custom is and it makes collaborating with others easier. If the code was just for me, it would all be in one big mono-repo. No question. It would be A LOT less work.
  - inferiorhuman 3y ago
    With all that said, I am a monorepo guy. Not for ideological reasons. For practical reasons. Yep. It's a balance. The big problem I have with large(r) repos is that everything git related is just slower and takes way more space. I've got some git prompt magic (using gitoxide of course) and it just drags with the rust repo. At one point I wanted to make some changes to a man page in FreeBSD. Sure, it's neat that there's thirty years of history. But it's thirty years of everything's history. Shallow cloning made it a bit more bearable, but the UX for trying to grab just a directory or two from a repo is still petty gnarly. But it's all just emacs vs vi all over again (and I've settled on helix and sublime anyhow).