3 ms·

I want to echo this point. I tried to write an implementation of an automata-based algorithm in Rust, and my main takeaway was that Rust really doesn't like lin

I want to echo this point. I tried to write an implementation of an automata-based algorithm in Rust, and my main takeaway was that Rust really doesn't like linked lists. There is currently a popular book [1] that focuses entirely on how one would write such a thing. That's not to say that it can't be done - I believe there's a crate implementing the same algorithm I was going for. But my main point is: if you see "systems programming" and think "oh, like C", then you are going to have a difficult time. [1] https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/

dpbriggs 7y ago
Totally agree. Anything that touches multiple owner territory gets ugly pretty fast. You end up with a variety of Cell objects, Rc::weak pointers, etc. Again it's possible but not trivial to figure out. Now I wish I read that resource before writing the library, as I would have saved a considerable amount of time (~30h / 2k lines of rust). Just using raw pointers (NonNull) everywhere meant comments like this [0] but was far more elegant and understandable overall. It was spooky seeing rust segfault before everything was ironed out + valgrind + miri tested. But it's also really nice to have the borrow checker figure out sketchy lifetime extensions / iterator invalidation for you. [0] https://github.com/dpbriggs/convenient-skiplist/blob/d781954b9a988a45c86591fbe6f76e99bb00722c/src/lib.rs#L871 https://github.com/dpbriggs/convenient-skiplist/blob/d781954...
quietbritishjim 7y ago
Rust newbie here. If you're working on a project like that, how bad (or even possible) would it be to just stick unsafe around almost everything, if the alternative is to use C++? I mean, unsafe Rust is still no worse than C/C++, right?
- probably_wrong 7y ago
  In my case, I wouldn't do it for two reasons. First, if the whole point of using Rust is "memory safety", then writing everything unsafe would be missing the entire point. I'd rather do it well at some time in the future, when I properly understand the language. Which leads me to my second point: at this point, I'd rather do it in C (which I did). I haven't done much C lately, but I'm at least aware of its strengths, weaknesses, and best practices. Better to use an old tool well than a new one badly. More expert Rust programmers can probably give a better answer.

dpbriggs 7y ago

Totally agree. Anything that touches multiple owner territory gets ugly pretty fast. You end up with a variety of Cell objects, Rc::weak pointers, etc. Again it's possible but not trivial to figure out. Now I wish I read that resource before writing the library, as I would have saved a considerable amount of time (~30h / 2k lines of rust). Just using raw pointers (NonNull) everywhere meant comments like this [0] but was far more elegant and understandable overall. It was spooky seeing rust segfault before everything was ironed out + valgrind + miri tested. But it's also really nice to have the borrow checker figure out sketchy lifetime extensions / iterator invalidation for you. [0] https://github.com/dpbriggs/convenient-skiplist/blob/d781954b9a988a45c86591fbe6f76e99bb00722c/src/lib.rs#L871 https://github.com/dpbriggs/convenient-skiplist/blob/d781954...

quietbritishjim 7y ago

Rust newbie here. If you're working on a project like that, how bad (or even possible) would it be to just stick unsafe around almost everything, if the alternative is to use C++? I mean, unsafe Rust is still no worse than C/C++, right?

probably_wrong 7y ago
In my case, I wouldn't do it for two reasons. First, if the whole point of using Rust is "memory safety", then writing everything unsafe would be missing the entire point. I'd rather do it well at some time in the future, when I properly understand the language. Which leads me to my second point: at this point, I'd rather do it in C (which I did). I haven't done much C lately, but I'm at least aware of its strengths, weaknesses, and best practices. Better to use an old tool well than a new one badly. More expert Rust programmers can probably give a better answer.