7 ms·

I personally dislike rust, but I love kernels, and so I'll always check these projects out. This is one of the nicer ones. It looks pretty conservative in i

I personally dislike rust, but I love kernels, and so I'll always check these projects out. This is one of the nicer ones. It looks pretty conservative in it's use of Rust's advanced features. The code looks pretty easy to read and follow. There's actually a decent amount of comments (for rust code). Not bad!

IshKebab 2y ago
Rust code is usually well commented in my experience.
- cies 2y ago
  Instead of asking "what other languages and project (open/closed, big/small, web/mobile/desktop, game/consumerapp/bizapp) have you experience with as to come to this conclusion?" people down vote you. So lemme ask: what other languages and project (open/closed, big/small, web/mobile/desktop, game/consumerapp/bizapp) have you experience with as to come to this conclusion?
  - dangsux 2y ago
    [dead]
  - ramon156 2y ago
    I expect the downvotes to be there because it's talking positively about rust, which is blasphemy! /j
    - tracker1 2y ago
      I'm guessing a lot of any perception of a lack of comments or documentation in a rust codebase comes down to how new or green a developer is to rust. If you're just starting out or doing something relatively simple, your goal is to get something working. This is so true regardless of the language.
      - jimbomins 2y ago
        I've never looked at any Rust. But this mini thread leaves me expecting the Rust world to be like Perl. The experienced Rust/Perl user uses every feature and short cut for magnificently dense expressive (alt. incomprehensible gibberish to anyone else) and doesn't comment it because the code is self evident. When actually they just want to code wank showing how clever they are and how lazy anyone else is if they haven't take the time to understand the details and thus understand. But like I said, I've not looked at any Rust despite its marketing success.
        tracker1 2y ago
        I've read a lot more Rust than I've written at this point... A lot of what I've seen has been really easy to reason with and follow. There are a few features that are a bit harder to grok, especially with complex access lifetimes. Generally those complexities have been more from the inexperienced as a lot of what I've seen from more experienced devs simplifies those complex points of interaction making the entirety more easy to reason with. I find a lot of the complexities tend to come from devs with more experience in communities that tend to add complexity by nature (C# and Java devs in particular). YMMV of course, that's just been my take so far. I've written a few simple web (micro)services in Rust and a couple of playground Tauri apps. I will say the simpler tasks have been incredibly easy to work through. Though I may not have always taken the absolutely most performant, least memory path of work, it's been smaller/faster than other platforms and languages I have more experience with. And that's without even getting into build/compile time optimization options.
- iknowstuff 2y ago
  for the downvoters: it’s true, and it’s because of rustdoc and doctests. comments become publicly browsable documentation, and any code contained within is run as a part of the test suite.
  - 1oooqooq 2y ago
    think the downvotes are because of relevance. point was not using advanced rust features, not being documented
    - forks 2y ago
      I don't see how the relevance is in question. GGGP said "There's actually a decent amount of comments (for rust code)." GGP seems to be responding to that parenthetical.
  - cgh 2y ago
    Javadoc pioneered this 25+ years ago and despite that, there's plenty of poorly-documented Java code out there. Orders of magnitude more of it than all of the Rust code in existence, in fact. Intuition tells me that Rust is young enough to attract a certain type of early adopter, the kind of programmer who is more likely to document their code well from the outset.
wg0 2y ago
Otherwise is a decent language but what makes it difficult is the borrow semantics and lifetimes. Lifetimes are more complicated to get your head around. But then there's this Arc, Ref, Pinning and what not - how deep is that rabbit hole?
- oneshtein 2y ago
  Rust lifetime is just a label for a region of memory with various data, which is discarded at the end of its life time. When compiler enters a function, it creates a memory block to hold data of all variables in the function, and then discards this block at the exit from the function, so these variables are valid for life time of the function call only.
- KingOfCoders 2y ago
  I always feel Arc is the admission that the borrow checker with different/overlapping lifetimes is too difficult, despite what many Rust developers - who liberally use Arc - claim.
  - Galanwe 2y ago
    It's not that the borrow checker is too difficult, it's that it's too limiting. The _static_ borrow checker can only check what is _statically_ verifiable, which is but a subset of valid programs. There are few things more frustrating than doing something you know is correct, but that you cannot express in your language.
    - netbsdusers 2y ago
      For kernels (and I suspect database engines might be added to the list, since they seem to have similar requirements to be both scalable and deal with massive amounts of shared state, but I'm not overly familiar with them) is where it gets particularly difficult. Several kernels for example use type-stable memory, memory that is guaranteed to only hold objects of a particular type, though perhaps only providing that guarantee for as long as you hold an RCU read-lock (this is the case in Linux with SLAB_TYPESAFE_BY_RCU). It is possible in some cases to be able to safely deal with references to objects where the "lifetime" of the referent has ended, but where by dint of it being guaranteed to be the same type of object, you can still do what you want to do. This comes in handy when you have a problem that commonly appears in kernels where you need to invert a typical lock ordering (a classic case is that the page fault codepath might want to lock, say, VM object then page queue, but the page-replacement codepath will want to lock page-queue then VM object.) Unfortunately it's hard to think of how the preconditions for these tricks could be formally expressed.

IshKebab 2y ago

Rust code is usually well commented in my experience.

cies 2y ago
Instead of asking "what other languages and project (open/closed, big/small, web/mobile/desktop, game/consumerapp/bizapp) have you experience with as to come to this conclusion?" people down vote you. So lemme ask: what other languages and project (open/closed, big/small, web/mobile/desktop, game/consumerapp/bizapp) have you experience with as to come to this conclusion?
- dangsux 2y ago
  [dead]
- ramon156 2y ago
  I expect the downvotes to be there because it's talking positively about rust, which is blasphemy! /j
  - tracker1 2y ago
    I'm guessing a lot of any perception of a lack of comments or documentation in a rust codebase comes down to how new or green a developer is to rust. If you're just starting out or doing something relatively simple, your goal is to get something working. This is so true regardless of the language.
    - jimbomins 2y ago
      I've never looked at any Rust. But this mini thread leaves me expecting the Rust world to be like Perl. The experienced Rust/Perl user uses every feature and short cut for magnificently dense expressive (alt. incomprehensible gibberish to anyone else) and doesn't comment it because the code is self evident. When actually they just want to code wank showing how clever they are and how lazy anyone else is if they haven't take the time to understand the details and thus understand. But like I said, I've not looked at any Rust despite its marketing success.
      - tracker1 2y ago
        I've read a lot more Rust than I've written at this point... A lot of what I've seen has been really easy to reason with and follow. There are a few features that are a bit harder to grok, especially with complex access lifetimes. Generally those complexities have been more from the inexperienced as a lot of what I've seen from more experienced devs simplifies those complex points of interaction making the entirety more easy to reason with. I find a lot of the complexities tend to come from devs with more experience in communities that tend to add complexity by nature (C# and Java devs in particular). YMMV of course, that's just been my take so far. I've written a few simple web (micro)services in Rust and a couple of playground Tauri apps. I will say the simpler tasks have been incredibly easy to work through. Though I may not have always taken the absolutely most performant, least memory path of work, it's been smaller/faster than other platforms and languages I have more experience with. And that's without even getting into build/compile time optimization options.
iknowstuff 2y ago
for the downvoters: it’s true, and it’s because of rustdoc and doctests. comments become publicly browsable documentation, and any code contained within is run as a part of the test suite.
- 1oooqooq 2y ago
  think the downvotes are because of relevance. point was not using advanced rust features, not being documented
  - forks 2y ago
    I don't see how the relevance is in question. GGGP said "There's actually a decent amount of comments (for rust code)." GGP seems to be responding to that parenthetical.
- cgh 2y ago
  Javadoc pioneered this 25+ years ago and despite that, there's plenty of poorly-documented Java code out there. Orders of magnitude more of it than all of the Rust code in existence, in fact. Intuition tells me that Rust is young enough to attract a certain type of early adopter, the kind of programmer who is more likely to document their code well from the outset.

wg0 2y ago

Otherwise is a decent language but what makes it difficult is the borrow semantics and lifetimes. Lifetimes are more complicated to get your head around. But then there's this Arc, Ref, Pinning and what not - how deep is that rabbit hole?

oneshtein 2y ago
Rust lifetime is just a label for a region of memory with various data, which is discarded at the end of its life time. When compiler enters a function, it creates a memory block to hold data of all variables in the function, and then discards this block at the exit from the function, so these variables are valid for life time of the function call only.
KingOfCoders 2y ago
I always feel Arc is the admission that the borrow checker with different/overlapping lifetimes is too difficult, despite what many Rust developers - who liberally use Arc - claim.
- Galanwe 2y ago
  It's not that the borrow checker is too difficult, it's that it's too limiting. The _static_ borrow checker can only check what is _statically_ verifiable, which is but a subset of valid programs. There are few things more frustrating than doing something you know is correct, but that you cannot express in your language.
  - netbsdusers 2y ago
    For kernels (and I suspect database engines might be added to the list, since they seem to have similar requirements to be both scalable and deal with massive amounts of shared state, but I'm not overly familiar with them) is where it gets particularly difficult. Several kernels for example use type-stable memory, memory that is guaranteed to only hold objects of a particular type, though perhaps only providing that guarantee for as long as you hold an RCU read-lock (this is the case in Linux with SLAB_TYPESAFE_BY_RCU). It is possible in some cases to be able to safely deal with references to objects where the "lifetime" of the referent has ended, but where by dint of it being guaranteed to be the same type of object, you can still do what you want to do. This comes in handy when you have a problem that commonly appears in kernels where you need to invert a typical lock ordering (a classic case is that the page fault codepath might want to lock, say, VM object then page queue, but the page-replacement codepath will want to lock page-queue then VM object.) Unfortunately it's hard to think of how the preconditions for these tricks could be formally expressed.