7 ms·

Really excited to see the syntax becoming more consistent! I am looking forward to master Rust in the coming 4-5 years.

axiosgunnar 5y ago
Since you said „master“ you are probably already somewhat proficient, but if not, I can not recommend enough to just try Rust out for some project one day. It literally took me 2 days from writing my first line of Rust to having a central component of our pipeline rewritten in Rust and running in production and I enjoy every minute of writing Rust, since (after you win the battle with the borrow checker) everything „just works“.
- throwaway894345 5y ago
  I also like writing Rust, but “After you win the battle with the borrow checker” is doing a lot of work. Those battles often crop up unexpectedly and sometimes they’re easily resolved and other times they require reworking your architecture—it’s very hard to estimate how long it will take. Of course, there are escape hatches—you can clone excessively, but it’s not all peaches and cream.
  - whatshisface 5y ago
    About 80% of my battles with the borrow checker eventually resolve with me realizing the code I'm trying to get working could lead to a bug in a case I hadn't considered. Of course, I could just be an abnormally sloppy programmer.
    - throwaway894345 5y ago
      In my experience, borrow checker errors would only be “bugs” in a program that doesn’t have a garbage collector or if there is shared memory parallelism involved. Put differently, if you slapped a borrow checker on Go and your program was single-threaded, (I posit but welcome correction) borrow-checker errors would probably not be uncovering many bugs.
      - dj_mc_merlin 5y ago
        Yes, the point of the borrow checker is memory safety without GC.
      - whatshisface 5y ago
        Not for me, it's usually something related to aliasing or iterator invalidation.
- afavour 5y ago
  I've written a fair amount of Rust and my beginner experience was not as positive as yours. It took me a very long time to fully deal with things like the borrow checker. My personal recommendation to anyone just writing code as a learning exercise is that they start with using Rc<> wherever a borrow checker-related issue arises. Then you can get used to the rest of Rust. Once you feel a lot more proficient you can go back and start replacing Rc<> with references (and you might find that you don't even need to in many instances anyway)
  - throwaway894345 5y ago
    This is interesting. I did `clone()` everywhere rather than `Rc<>` I wonder how these approaches compare?
    - Klasiaster 5y ago
      For the read-only case it's the same except for a larger overhead of the cloning. But for the case where the data is modified, Rc often goes with RefCell as Rc<RefCell<X>> and allows in-place mutation called interior mutability. This means that the other code that got the copy of the Rc will observe the write effects.
    - steveklabnik 5y ago
      On most things, clone() will make a full copy. If your type is wrapped in Rc<T>, then calling clone() on it will increase a reference count. So it ends up being cheaper. If you were mutating things, though, you'll need extra stuff in the Rc<T> case, though. If you're mutating in the regular case, you'd be changing the copies, of course, so the originals wouldn't change.
- chrismorgan 5y ago
  Battles with the borrow checker are seldom won. Victory is conceding that the compiler knows better than you and fixing your design. (I’m serious about this, as a user for eight years and casual trainer for several. The fact of the matter is that when the borrow checker complains, it’s right to complain, >99.99% of the time, even if you had thought carefully about it and were sure you got it right and that the compiler’s complaint was unnecessary.)
  - thethirdone 5y ago
    I would lower the percentage it is right to complain about to only 99.9% (without non-lexical lifetimes it is probably only right 99% of the time). I have encountered like 3 cases where the borrow checker complained and forced me to make a worse design. I think I have seen more than 1000 and less than 10,000 borrow checking errors.
- SatvikBeri 5y ago
  Two days is fast! What background were you coming from – did you have previous experience with non-gc languages?
  - axiosgunnar 5y ago
    Actually it was two weeks - I mistyped. And no, I did not have non-gc-language experience but tbh Rust feels like a gc-language to me? I don't "feel" like I'm writing C code you know?
    - brabel 5y ago
      holy shit, I was feeling like an idiot to know someone can actually get to grips with Rust basics in just 2 days :D took me more like two months to stop struggling constantly on every line I wrote!
      - bombela 5y ago
        I have pushed people to learn Rust. And I noted that the more experience in software design a person has, the easier it is for them to truly internalize the borrow checker. I suspect this is because you naturally get to an instinctive form of ownership model similar to Rust. Since it is a really good way to reduce complexity. Rust then, merely formalizes and name it for you.
        theon144 5y ago
        >And I noted that the more experience in software design a person has, the easier it is for them to truly internalize the borrow checker. I feel like this verges dangerously close to patting ourselves on the back, but... >I suspect this is because you naturally get to an instinctive form of ownership model similar to Rust. I do feel this is more or less correct. I've only had a literal handful of "battles" with the borrow checker (over a couple months spent with Rust); the rest seemed to naturally parallel the ownership semantics I wanted in my code anyway. Ownership meaning everything from "where does a value arise" to "what parts of the code have access to that value in the first place". It forced - or rather nudged - me to think about my architecture in a way that led to a rather clear design, although it might have taken longer than in another language. In another words, I did move slower, but refactoring is much easier and less frequently needed, and that's a tradeoff I'm all for.
- tick_tock_tick 5y ago
  I would never trust something anything I've only been exposed to for two days in production. The chance of some kind of subtle error is wayyyy too high.

Since you said „master“ you are probably already somewhat proficient, but if not, I can not recommend enough to just try Rust out for some project one day. It literally took me 2 days from writing my first line of Rust to having a central component of our pipeline rewritten in Rust and running in production and I enjoy every minute of writing Rust, since (after you win the battle with the borrow checker) everything „just works“.

throwaway894345 5y ago
I also like writing Rust, but “After you win the battle with the borrow checker” is doing a lot of work. Those battles often crop up unexpectedly and sometimes they’re easily resolved and other times they require reworking your architecture—it’s very hard to estimate how long it will take. Of course, there are escape hatches—you can clone excessively, but it’s not all peaches and cream.
- whatshisface 5y ago
  About 80% of my battles with the borrow checker eventually resolve with me realizing the code I'm trying to get working could lead to a bug in a case I hadn't considered. Of course, I could just be an abnormally sloppy programmer.
  - throwaway894345 5y ago
    In my experience, borrow checker errors would only be “bugs” in a program that doesn’t have a garbage collector or if there is shared memory parallelism involved. Put differently, if you slapped a borrow checker on Go and your program was single-threaded, (I posit but welcome correction) borrow-checker errors would probably not be uncovering many bugs.
    - dj_mc_merlin 5y ago
      Yes, the point of the borrow checker is memory safety without GC.
    - whatshisface 5y ago
      Not for me, it's usually something related to aliasing or iterator invalidation.
afavour 5y ago
I've written a fair amount of Rust and my beginner experience was not as positive as yours. It took me a very long time to fully deal with things like the borrow checker. My personal recommendation to anyone just writing code as a learning exercise is that they start with using Rc<> wherever a borrow checker-related issue arises. Then you can get used to the rest of Rust. Once you feel a lot more proficient you can go back and start replacing Rc<> with references (and you might find that you don't even need to in many instances anyway)
- throwaway894345 5y ago
  This is interesting. I did `clone()` everywhere rather than `Rc<>` I wonder how these approaches compare?
  - Klasiaster 5y ago
    For the read-only case it's the same except for a larger overhead of the cloning. But for the case where the data is modified, Rc often goes with RefCell as Rc<RefCell<X>> and allows in-place mutation called interior mutability. This means that the other code that got the copy of the Rc will observe the write effects.
  - steveklabnik 5y ago
    On most things, clone() will make a full copy. If your type is wrapped in Rc<T>, then calling clone() on it will increase a reference count. So it ends up being cheaper. If you were mutating things, though, you'll need extra stuff in the Rc<T> case, though. If you're mutating in the regular case, you'd be changing the copies, of course, so the originals wouldn't change.
chrismorgan 5y ago
Battles with the borrow checker are seldom won. Victory is conceding that the compiler knows better than you and fixing your design. (I’m serious about this, as a user for eight years and casual trainer for several. The fact of the matter is that when the borrow checker complains, it’s right to complain, >99.99% of the time, even if you had thought carefully about it and were sure you got it right and that the compiler’s complaint was unnecessary.)
- thethirdone 5y ago
  I would lower the percentage it is right to complain about to only 99.9% (without non-lexical lifetimes it is probably only right 99% of the time). I have encountered like 3 cases where the borrow checker complained and forced me to make a worse design. I think I have seen more than 1000 and less than 10,000 borrow checking errors.
SatvikBeri 5y ago
Two days is fast! What background were you coming from – did you have previous experience with non-gc languages?
- axiosgunnar 5y ago
  Actually it was two weeks - I mistyped. And no, I did not have non-gc-language experience but tbh Rust feels like a gc-language to me? I don't "feel" like I'm writing C code you know?
  - brabel 5y ago
    holy shit, I was feeling like an idiot to know someone can actually get to grips with Rust basics in just 2 days :D took me more like two months to stop struggling constantly on every line I wrote!
    - bombela 5y ago
      I have pushed people to learn Rust. And I noted that the more experience in software design a person has, the easier it is for them to truly internalize the borrow checker. I suspect this is because you naturally get to an instinctive form of ownership model similar to Rust. Since it is a really good way to reduce complexity. Rust then, merely formalizes and name it for you.
      - theon144 5y ago
        >And I noted that the more experience in software design a person has, the easier it is for them to truly internalize the borrow checker. I feel like this verges dangerously close to patting ourselves on the back, but... >I suspect this is because you naturally get to an instinctive form of ownership model similar to Rust. I do feel this is more or less correct. I've only had a literal handful of "battles" with the borrow checker (over a couple months spent with Rust); the rest seemed to naturally parallel the ownership semantics I wanted in my code anyway. Ownership meaning everything from "where does a value arise" to "what parts of the code have access to that value in the first place". It forced - or rather nudged - me to think about my architecture in a way that led to a rather clear design, although it might have taken longer than in another language. In another words, I did move slower, but refactoring is much easier and less frequently needed, and that's a tradeoff I'm all for.
tick_tock_tick 5y ago
I would never trust something anything I've only been exposed to for two days in production. The chance of some kind of subtle error is wayyyy too high.