3 ms·

99.99% of Rust programmers don't have to care about this issue, it's just nailing down some spots where the safety invariants can deliberately be broken. The i

99.99% of Rust programmers don't have to care about this issue, it's just nailing down some spots where the safety invariants can deliberately be broken. The issue isn't actually async here, it's #[fundamental]. The holes it pokes in the orphan rule system lead to many unintentional outcomes.

howinteresting 4y ago
BTW I think the fact that in Go, your program can change out from underneath you based on whether an array gets realloced is so much more disturbing: https://utcc.utoronto.ca/~cks/space/blog/programming/GoSlicesVsPointers https://utcc.utoronto.ca/~cks/space/blog/programming/GoSlice... It is genuinely shocking to me that people just live with this. This is completely inexpressible with safe Rust, as it should be.
- bsaul 4y ago
  the way arrays work and that they can reallocate on append is clearly visible by the fact that it returns the pointer to the new array. It is something you learn very early, because the syntax is indeed a bit peculiar, and kind of a footgun. However it implicits teaches you to not try to play with the memory backing the array (which is something go programmers are very happy not doing).
  - howinteresting 4y ago
    Personally, I would simply use a language where such footguns just don't exist.
    - bsaul 4y ago
      That was my first conclusion with that language after my first attempt. However on the second one, much later, i came to realize this language is an absolute marvel of carefully picked tradeofs, always in favor of simplicity and maintainability. Which for industry project is a must. Go footguns are pretty easy to spot and look « stupid » ( in the sense that other languages solve them elegantly). In exchange, the really hard ones (such as overly complex concurrency patterns, or codebases made of layers upon layers or crappy abstractions) are extremely rare and need constant fighting against the language.
      - howinteresting 4y ago
        I'd say that in my professional experience, Rust is probably the best "at scale" language that exists today.

howinteresting 4y ago

BTW I think the fact that in Go, your program can change out from underneath you based on whether an array gets realloced is so much more disturbing: https://utcc.utoronto.ca/~cks/space/blog/programming/GoSlicesVsPointers https://utcc.utoronto.ca/~cks/space/blog/programming/GoSlice... It is genuinely shocking to me that people just live with this. This is completely inexpressible with safe Rust, as it should be.

bsaul 4y ago
the way arrays work and that they can reallocate on append is clearly visible by the fact that it returns the pointer to the new array. It is something you learn very early, because the syntax is indeed a bit peculiar, and kind of a footgun. However it implicits teaches you to not try to play with the memory backing the array (which is something go programmers are very happy not doing).
- howinteresting 4y ago
  Personally, I would simply use a language where such footguns just don't exist.
  - bsaul 4y ago
    That was my first conclusion with that language after my first attempt. However on the second one, much later, i came to realize this language is an absolute marvel of carefully picked tradeofs, always in favor of simplicity and maintainability. Which for industry project is a must. Go footguns are pretty easy to spot and look « stupid » ( in the sense that other languages solve them elegantly). In exchange, the really hard ones (such as overly complex concurrency patterns, or codebases made of layers upon layers or crappy abstractions) are extremely rare and need constant fighting against the language.
    - howinteresting 4y ago
      I'd say that in my professional experience, Rust is probably the best "at scale" language that exists today.