4 ms·

I don't consider myself a particularly good programmer, and I don't find the burrow checker is a substantial source of cognitive load. I think I get way more f

I don't consider myself a particularly good programmer, and I don't find the burrow checker is a substantial source of cognitive load. I think I get way more friction from: - library authors that go crazy with generics. - the million ways rust makes performance tradeoffs explicit (even when you're writing part of the program where performance simply doesn't matter). - the million-and-one things you can do with an option type. - the arcane macro syntax. I could probably go on. I've been writing a lot of rust because I wanted a low-ish level language with good C interop, and I didn't want to learn C++, so I wasn't at any point a rust fanboy. I very much appreciate not having to be a genius to avoid segmentation faults, but other than that, I think rust is a somewhat ugly language - for the simple reason that it has a lot of features, some of which partially overlap, and most of which are vaguely inconsistent. I'm probably sounding a bit harsher than I mean to - obviously, you can't expect a language like rust to have the simplicity and consistency of something like lua, and by and large, it's better than anything else I write programs in. Still, the point is, as somebody with a lot of (fair and unfair) complaints, the burrow checker is not one of them. It complains rarely, and when it does you're almost always doing something stupid, unless you're doing something fairly arcane, in which case, you should probably use unsafe.

bcrosby95 6y ago
Then you're a good programmer. Rust effectively forces you to code like you're writing a multi-threaded app even when you aren't. There's a reason why people suck at writing multi-threaded apps: because it's hard. This is what people are fighting when they fight the borrow checker. And this is why so many people find it frustrating. There's all sorts of designs that flat out don't work or are way more effort than they're worth.
- jolux 6y ago
  it's not just about multi-threading, it's also about actually dealing with memory in a way that's safe in a single thread as well without introducing GC, which we know from C is hard too
  - bcrosby95 6y ago
    In my experience most of the painful difficulties people have with the borrow checker is because it works like a read-write lock. AFAIK this aspect isn't required to have safe single threaded code without a GC.
    - bitwize 6y ago
      It is if you want to have automatic deallocation with a strict guarantee of memory safety including no use-after-free bugs.
      - bcrosby95 6y ago
        How does this relate to whether or not you plan to mutate things? Wouldn't plain ole counting work for this, regardless of whether or not they're mutable, rather than what Rust does - allowing multiple readers and no writers, or zero readers and 1 writer?
        erik_seaberg 6y ago
        Refcounting is GC; it automatically detects at runtime that an object has no references. It also adds a substantial cost that Rust is trying to avoid, often by copying immutable objects (which have better cache locality than random access to refcounts everywhere).
        bcrosby95 6y ago
        I'm not talking about GC. I'm talking about Rust references: https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html https://doc.rust-lang.org/book/ch04-02-references-and-borrow... > At any given time, you can have either one mutable reference or any number of immutable references.
        erik_seaberg 6y ago
        Oh, I get it, you're suggesting all references could be mutable, but still limited to the lifetime of the object. I guess the downside would be that you can't design an API like iterator invalidation that relies on "some (mutable) methods can't be called while any other (immutable) references exist".
- aliceryhl 6y ago
  This is a really common misconception, but all of the borrow checker's rules are necessary to fully verify the memory safety of single-threaded programs too. It just turns out that mathematically proving GC-free code to be free of use-after-free and double-free errors is really difficult unless you disallow a lot of things.
slimsag 6y ago
This is exactly the same thing I can relate to coming from a Go background trying to use Rust.

bcrosby95 6y ago

Then you're a good programmer. Rust effectively forces you to code like you're writing a multi-threaded app even when you aren't. There's a reason why people suck at writing multi-threaded apps: because it's hard. This is what people are fighting when they fight the borrow checker. And this is why so many people find it frustrating. There's all sorts of designs that flat out don't work or are way more effort than they're worth.

jolux 6y ago
it's not just about multi-threading, it's also about actually dealing with memory in a way that's safe in a single thread as well without introducing GC, which we know from C is hard too
- bcrosby95 6y ago
  In my experience most of the painful difficulties people have with the borrow checker is because it works like a read-write lock. AFAIK this aspect isn't required to have safe single threaded code without a GC.
  - bitwize 6y ago
    It is if you want to have automatic deallocation with a strict guarantee of memory safety including no use-after-free bugs.
    - bcrosby95 6y ago
      How does this relate to whether or not you plan to mutate things? Wouldn't plain ole counting work for this, regardless of whether or not they're mutable, rather than what Rust does - allowing multiple readers and no writers, or zero readers and 1 writer?
      - erik_seaberg 6y ago
        Refcounting is GC; it automatically detects at runtime that an object has no references. It also adds a substantial cost that Rust is trying to avoid, often by copying immutable objects (which have better cache locality than random access to refcounts everywhere).
        bcrosby95 6y ago
        I'm not talking about GC. I'm talking about Rust references: https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html https://doc.rust-lang.org/book/ch04-02-references-and-borrow... > At any given time, you can have either one mutable reference or any number of immutable references.
        erik_seaberg 6y ago
        Oh, I get it, you're suggesting all references could be mutable, but still limited to the lifetime of the object. I guess the downside would be that you can't design an API like iterator invalidation that relies on "some (mutable) methods can't be called while any other (immutable) references exist".
aliceryhl 6y ago
This is a really common misconception, but all of the borrow checker's rules are necessary to fully verify the memory safety of single-threaded programs too. It just turns out that mathematically proving GC-free code to be free of use-after-free and double-free errors is really difficult unless you disallow a lot of things.

slimsag 6y ago

This is exactly the same thing I can relate to coming from a Go background trying to use Rust.