5 ms·

That was not my experience. I still fought the borrow checker after a year of using Rust. And I found many situations while using Rust where I either needed t

by ptato 4y ago

That was not my experience. I still fought the borrow checker after a year of using Rust. And I found many situations while using Rust where I either needed to clone, or use unsafe where it's easier to make a mistake than in other languages because the syntax is extremely unergonomic and the memory semantics are much less clear.

kitkat_new 4y ago
can you give examples please?
- ptato 4y ago
  It's been ~a year. I can't remember. It usually had to do with the dreaded self referential structures, or interfacing with c libs.
  - littlestymaar 4y ago
    For Self referential struct, the typical answer is twofold: - try to design your code not to need them. - if you really need one, you can either use smart pointers (Rc & RefCell) or use unsafe and use the Pin API to be sure that you won't accidentally move your struct. That being said, it's not easier in C (or at least, it's easier to write, but also very easy to misuse), since a memcopy will silently break your self-referential struct. Do Zig has “Copy constructors” like C++ to avoid this issue?
    - ok123456 4y ago
      In most situations those are horrible non-solutions. Ref counted cells can't be used in self-referential structures because you'll introduce cycles. So, you'll go through all this trouble just to make memory leaks in the end. "Designing your code not to need them" usually means implementing a worse version of a data structure from first principles. The only real answer is to write "unsafe" Rust here and there. Which is fine. But, to the prevailing Rust community that is absolutely heretical.
      - littlestymaar 4y ago
        > Ref counted cells can't be used in self-referential structures because you'll introduce cycles. So, you'll go through all this trouble just to make memory leaks in the end. You know about Weak references right? > "Designing your code not to need them" usually means implementing a worse version of a data structure from first principles. > The only real answer is to write "unsafe" Rust here and there. Which is fine. If it's a specific “data structure” (1% of the time) and not just the way you've decided to structure your current code (99% of the time), then using unsafe is fine. > But, to the prevailing Rust community that is absolutely heretical. No, the rust community is totally fine with reasonable unsafe code (you don't see burntsushi being harassed for using unsafe in his crates for instance), rustaceans hate (to a point which leads to excessive behaviors) unsound code, like the Actix drama, where the author used unsafe in unsound ways (not checking invariants in any way, and declaring “safe” functions that could cause segfault is used incorrectly). But unsafe code used properly is fine.
        ok123456 4y ago
        Yes, I'm aware of weak references and I'm aware that they're not a universal solution to this problem. You risk having something removed as unused while it's actually still being used if you don't have some strong reference to it somewhere. As to your assertion that this is only '1%' of code, it really depends on what you're doing. If you're just gluing together modules that's where linear types for memory are an applicable model. But, if you are actually designing some structure yourself, it's not an applicable model. The Actix 'drama' is reason alone to avoid the rust 'community'. I'll wait for these features to make it in a language with better ergonomics, a large commercial backer, and professionals at the helm who are less religious about how mere mortals use their language and are willing to err on being more pragmatic about it.
        littlestymaar 4y ago
        > Yes, I'm aware of weak references and I'm aware that they're not a universal solution to this problem. You risk having something removed as unused while it's actually still being used if you don't have some strong reference to it somewhere. In graphs yes, but we're talking about self-referential structure here, and there you don't face this risk: the self-reference should always be a weak reference (the struct should be dropped when and only when the external references are gone, the internal ones don't count). > As to your assertion that this is only '1%' of code, it really depends on what you're doing. If you're just gluing together modules that's where linear types for memory are an applicable model. But, if you are actually designing some structure yourself, it's not an applicable model. Either you're implementing a data structure from a research paper (and you're in the 1% case and unsafe is fine) or you are actually using such a data structure and you don't have to perform this gymnastic by yourself. In C, people tend to reimplement data structures in their project because the dependency management story is quite dated, but it's not something anyone else does in other languages: most of the time you just import the standard library's data structure (or someone else's) and call it a day. > The Actix 'drama' is reason alone to avoid the rust 'community'. You'll find internet mobs in any group of people, unfortunately… > I'll wait for these features to make it in a language with better ergonomics, a large commercial backer If you expect larger backers than Amazon, Microsoft, Facebook and Google combined[1], I think you'll need to hold your breath much too long for your own good… > and professionals at the helm who are less religious about how mere mortals use their language and are willing to err on being more pragmatic about it. You're confusing redditors (the actix stuff took place on /r/rust) and the language management… [1]https://foundation.rust-lang.org/members/ https://foundation.rust-lang.org/members/
littlestymaar 4y ago
> I still fought the borrow checker after a year of using Rust. That's interesting. How much Rust did you use during that year? And how level of proficiency did you reach? > And I found many situations while using Rust where I either needed to clone, or use unsafe That sounds like an uncommon trade-off. From my experience, the trade-off was usually “clone or put lifetime parameters everywhere”, which is annoying (and I really wish Rust analyzer could help with at some point, because it's pretty mechanical), but it was quite rare, because most of the time you can just move things (that is transferring ownership), unlike in C where you have either a copy or a pointer. > or use unsafe where it's easier to make a mistake than in other languages because the syntax is extremely unergonomic and the memory semantics are much less clear. This is unfortunately true. Miri helps, but there's a wide margin for improvement on that front.
- ptato 4y ago
  > How much Rust did you use during that year? And how level of proficiency did you reach? What kind of answer do you expect to these questions?
  - littlestymaar 4y ago
    For the first one, something between: “I was learning Rust on my spare time” and “I was working full time in a Rust-centric team”. And the second one is more subjective, about how confident you considered yourself with the language and how familiar you felt with its concepts.
ModernMech 4y ago
I'd say that after using Rust for a year I also fought the borrow checker, but after using Rust for 6 years I definitely don't anymore. A lot of the difference between a year and 6 was unlearning C++ habits.

by ptato 4y ago

kitkat_new 4y ago

can you give examples please?

ptato 4y ago
It's been ~a year. I can't remember. It usually had to do with the dreaded self referential structures, or interfacing with c libs.
- littlestymaar 4y ago
  For Self referential struct, the typical answer is twofold: - try to design your code not to need them. - if you really need one, you can either use smart pointers (Rc & RefCell) or use unsafe and use the Pin API to be sure that you won't accidentally move your struct. That being said, it's not easier in C (or at least, it's easier to write, but also very easy to misuse), since a memcopy will silently break your self-referential struct. Do Zig has “Copy constructors” like C++ to avoid this issue?
  - ok123456 4y ago
    In most situations those are horrible non-solutions. Ref counted cells can't be used in self-referential structures because you'll introduce cycles. So, you'll go through all this trouble just to make memory leaks in the end. "Designing your code not to need them" usually means implementing a worse version of a data structure from first principles. The only real answer is to write "unsafe" Rust here and there. Which is fine. But, to the prevailing Rust community that is absolutely heretical.
    - littlestymaar 4y ago
      > Ref counted cells can't be used in self-referential structures because you'll introduce cycles. So, you'll go through all this trouble just to make memory leaks in the end. You know about Weak references right? > "Designing your code not to need them" usually means implementing a worse version of a data structure from first principles. > The only real answer is to write "unsafe" Rust here and there. Which is fine. If it's a specific “data structure” (1% of the time) and not just the way you've decided to structure your current code (99% of the time), then using unsafe is fine. > But, to the prevailing Rust community that is absolutely heretical. No, the rust community is totally fine with reasonable unsafe code (you don't see burntsushi being harassed for using unsafe in his crates for instance), rustaceans hate (to a point which leads to excessive behaviors) unsound code, like the Actix drama, where the author used unsafe in unsound ways (not checking invariants in any way, and declaring “safe” functions that could cause segfault is used incorrectly). But unsafe code used properly is fine.
      - ok123456 4y ago
        Yes, I'm aware of weak references and I'm aware that they're not a universal solution to this problem. You risk having something removed as unused while it's actually still being used if you don't have some strong reference to it somewhere. As to your assertion that this is only '1%' of code, it really depends on what you're doing. If you're just gluing together modules that's where linear types for memory are an applicable model. But, if you are actually designing some structure yourself, it's not an applicable model. The Actix 'drama' is reason alone to avoid the rust 'community'. I'll wait for these features to make it in a language with better ergonomics, a large commercial backer, and professionals at the helm who are less religious about how mere mortals use their language and are willing to err on being more pragmatic about it.
        littlestymaar 4y ago
        > Yes, I'm aware of weak references and I'm aware that they're not a universal solution to this problem. You risk having something removed as unused while it's actually still being used if you don't have some strong reference to it somewhere. In graphs yes, but we're talking about self-referential structure here, and there you don't face this risk: the self-reference should always be a weak reference (the struct should be dropped when and only when the external references are gone, the internal ones don't count). > As to your assertion that this is only '1%' of code, it really depends on what you're doing. If you're just gluing together modules that's where linear types for memory are an applicable model. But, if you are actually designing some structure yourself, it's not an applicable model. Either you're implementing a data structure from a research paper (and you're in the 1% case and unsafe is fine) or you are actually using such a data structure and you don't have to perform this gymnastic by yourself. In C, people tend to reimplement data structures in their project because the dependency management story is quite dated, but it's not something anyone else does in other languages: most of the time you just import the standard library's data structure (or someone else's) and call it a day. > The Actix 'drama' is reason alone to avoid the rust 'community'. You'll find internet mobs in any group of people, unfortunately… > I'll wait for these features to make it in a language with better ergonomics, a large commercial backer If you expect larger backers than Amazon, Microsoft, Facebook and Google combined[1], I think you'll need to hold your breath much too long for your own good… > and professionals at the helm who are less religious about how mere mortals use their language and are willing to err on being more pragmatic about it. You're confusing redditors (the actix stuff took place on /r/rust) and the language management… [1]https://foundation.rust-lang.org/members/ https://foundation.rust-lang.org/members/

littlestymaar 4y ago

> I still fought the borrow checker after a year of using Rust. That's interesting. How much Rust did you use during that year? And how level of proficiency did you reach? > And I found many situations while using Rust where I either needed to clone, or use unsafe That sounds like an uncommon trade-off. From my experience, the trade-off was usually “clone or put lifetime parameters everywhere”, which is annoying (and I really wish Rust analyzer could help with at some point, because it's pretty mechanical), but it was quite rare, because most of the time you can just move things (that is transferring ownership), unlike in C where you have either a copy or a pointer. > or use unsafe where it's easier to make a mistake than in other languages because the syntax is extremely unergonomic and the memory semantics are much less clear. This is unfortunately true. Miri helps, but there's a wide margin for improvement on that front.

ptato 4y ago
> How much Rust did you use during that year? And how level of proficiency did you reach? What kind of answer do you expect to these questions?
- littlestymaar 4y ago
  For the first one, something between: “I was learning Rust on my spare time” and “I was working full time in a Rust-centric team”. And the second one is more subjective, about how confident you considered yourself with the language and how familiar you felt with its concepts.

ModernMech 4y ago

I'd say that after using Rust for a year I also fought the borrow checker, but after using Rust for 6 years I definitely don't anymore. A lot of the difference between a year and 6 was unlearning C++ habits.