4 ms·

Yep. Honestly, I don't find it too difficult to parse new languages even if they aren't C-like or Python-like (or Matlab-like or BASIC-like). I don't know Java,

Yep. Honestly, I don't find it too difficult to parse new languages even if they aren't C-like or Python-like (or Matlab-like or BASIC-like). I don't know Java, but I can read the Falstad circuit simulator source. It's just... very recognizable code patterns---almost a dialect of C++. I'm not a database expert, but I became comfortable with SQL this past year so I could better understand how my company's office software is structured. I can cobble together enough Javascript to create an own online sheet music book using abcjs, a directory full of ABC files, and jquery. I was able to barge through enough C# to write a crude 2D game during a game hackathon in college. In fact, AFTER learning Python, a lot of C became easier because I knew HOW a data structure should behave, which then influenced how I would create it from structs and functions. However. I get hung up on Kotlin. Kotlin reminds me a lot of Rust in its syntax, and Android has the same habit of renaming every single concept. In general, the more keywords and syntaxes two languages have in common, the easier to read. (In SQL's case, I think the relative lack of keywords and rigid query structure made this a nonissue.) So, mixed bag.

inferiorhuman 3y ago
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

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.