4 ms·

> The compiler helps a lot with its useful error messages. As someone trying very hard to love Rust this is just simply not the case. It takes the shortest pat

by zer8k 3y ago

> The compiler helps a lot with its useful error messages. As someone trying very hard to love Rust this is just simply not the case. It takes the shortest path to most answers. The most trivial example where the compiler becomes less helpful is a self-balancing binary tree. It will constantly suggest explicit lifetimes and other magic when in reality you probably want `Box<Rc<..>>`. It will suggest Boxing for recursive types...but that's about the end of it. In many cases you're better off knowing what to do. But the problem is knowing what to do requires you to have done what you need...and hence the Rust Ouroboros is born. The nice thing about unsafe code (C, for example) is the cognitive overhead is initially very low. That allows you to get an idea down and then worry about stuff later. Of course, if you have a gun to your head from management you never get to the "worry about stuff later" stage and introduce all sorts of nasty bugs. Rust frontloads all of this making it sometimes very difficult to use without having everything already thought out way ahead of time. Both a benefit and a curse.

mtsr 3y ago
It’s just the compiler assuming you know what you’re doing. You’re building this data structure on the stack, so it’ll point out where you’re not sufficiently explaining to it how the lifetimes of your code are safe. And even if you build it on the heap (using Box) you’ll still need to get the ownership right (using e.g. Rc). There’s only so many variations that work for something like trees (especially with doubly linked nodes) in any language, without either inherently unsafe lifetimes (because the particular language can’t express them as part of the API) or some kind of indirection (such as ECS style indices). Or garbage collection or ref counting, but one probably uses Rust to be able to control that kind of overhead instead of having to use whatever the language creators picked. If you want to learn about this, instead of using a ‘blessed’ implementation, read “too many linked lists” https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/. As for the front-loading comment: yes, Rust requires you to get some things right from the start, particularly ownership and lifetimes. If you want to work in Rust like in a scripting language, you can just use Box, Rc and clone() everywhere. But getting it right without those might require a significantly different API. Which isn’t that much different with your rough C implementation. To get any kind of safe API there will require just as many changes (if not more).
estebank 3y ago
> It will constantly suggest explicit lifetimes and other magic when in reality you probably want `Box<Rc<..>>`. If you can provide examples of cases like these, please file a ticket in the issue tracker. Some suggestions have to be overly cautious in order to not lead people astray, so having examples of common (or uncommon!) things people try that could use with some "human touch" in what direction they should take instead is very useful and welcome.
- mtsr 3y ago
  I wonder how tractable it would be for the compiler to suggest when your API needs Rc or boxing without being just as wrong in other cases. I think now that too many lists is part of the book, maybe the compiler can link to that in some cases, hah.
  - estebank 3y ago
    > I wonder how tractable it would be for the compiler to suggest when your API needs Rc or boxing without being just as wrong in other cases. A lot of the cases I've seen so far require some kind of global analysis, that we don't have today. But if we can have some kind of local analysis that will be reliable for a subset of cases, I'd jump at the opportunity to add it. > I think now that too many lists is part of the book, maybe the compiler can link to that in some cases, hah. That's not a bad idea, we already link to the book when it seems appropriate.

by zer8k 3y ago

mtsr 3y ago

It’s just the compiler assuming you know what you’re doing. You’re building this data structure on the stack, so it’ll point out where you’re not sufficiently explaining to it how the lifetimes of your code are safe. And even if you build it on the heap (using Box) you’ll still need to get the ownership right (using e.g. Rc). There’s only so many variations that work for something like trees (especially with doubly linked nodes) in any language, without either inherently unsafe lifetimes (because the particular language can’t express them as part of the API) or some kind of indirection (such as ECS style indices). Or garbage collection or ref counting, but one probably uses Rust to be able to control that kind of overhead instead of having to use whatever the language creators picked. If you want to learn about this, instead of using a ‘blessed’ implementation, read “too many linked lists” https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/. As for the front-loading comment: yes, Rust requires you to get some things right from the start, particularly ownership and lifetimes. If you want to work in Rust like in a scripting language, you can just use Box, Rc and clone() everywhere. But getting it right without those might require a significantly different API. Which isn’t that much different with your rough C implementation. To get any kind of safe API there will require just as many changes (if not more).

estebank 3y ago

> It will constantly suggest explicit lifetimes and other magic when in reality you probably want `Box<Rc<..>>`. If you can provide examples of cases like these, please file a ticket in the issue tracker. Some suggestions have to be overly cautious in order to not lead people astray, so having examples of common (or uncommon!) things people try that could use with some "human touch" in what direction they should take instead is very useful and welcome.

mtsr 3y ago
I wonder how tractable it would be for the compiler to suggest when your API needs Rc or boxing without being just as wrong in other cases. I think now that too many lists is part of the book, maybe the compiler can link to that in some cases, hah.
- estebank 3y ago
  > I wonder how tractable it would be for the compiler to suggest when your API needs Rc or boxing without being just as wrong in other cases. A lot of the cases I've seen so far require some kind of global analysis, that we don't have today. But if we can have some kind of local analysis that will be reliable for a subset of cases, I'd jump at the opportunity to add it. > I think now that too many lists is part of the book, maybe the compiler can link to that in some cases, hah. That's not a bad idea, we already link to the book when it seems appropriate.