5 ms·

Right. I attempted using Rust for trading-related code as well. However, I failed to write a dynamically linked always sorted order book where you can splice or

Right. I attempted using Rust for trading-related code as well. However, I failed to write a dynamically linked always sorted order book where you can splice orders in the middle. It is just too dynamic for Rust. Borrow checker killed me. And don't get me started on dynamic graphs. I would happily use Rust over C++ if it had all other improvements but similar memory management. I am completely unproductive with Rust model.

sunshowers 1y ago
I apologize for the naive question, but that sounds like a heap?
- jpc0 1y ago
  In my experience you need to approach this with vec or arrays of some sort and pass indices around… “We have pointers at home” behaviour. This is fine but coming from C++ it definitely feels weird…
  - bigstrat2003 1y ago
    Why not just use pointers? Rust has them, they aren't evil or anything. If you need to make a data structure that isn't feasible with references due to the borrow checker (such as a linked list), there's absolutely nothing wrong with using pointers.
    - atemerev 1y ago
      And it will look like this: https://rust-unofficial.github.io/too-many-lists/sixth-final.html https://rust-unofficial.github.io/too-many-lists/sixth-final... (filled with boilerplate, strange Rust idioms, borrow_unchecked, phantomdata, and you still have to manage lifetimes annotations).
      - bigstrat2003 1y ago
        And? I don't really see the issue. It works, it is sound, and it has a nice clean interface for safe code to use. That's all I really ask for. Lots of useful things in programming are quite gnarly under the hood, but that doesn't mean those things aren't worth using.
        uecker 1y ago
        It is fine, there is just not much Rust safety advantage left then. Also in C/C++ the errors do not usually occur when using a nicely defined API, but when doing the low-level gnarly stuff and getting it wrong. As said before, I think there is some advantage of Rust having a safe and unsafe subset, but is is nowhere as big as people claim it is.
        bigstrat2003 1y ago
        > It is fine, there is just not much Rust safety advantage left then. There's exactly as much as there was before though. The entire point of the Rust safety paradigm is that you can guarantee that unsafe code is confined to only where it is needed. Nobody ever promised "you will never have to write unsafe code", because that would be clearly unfeasible for the systems programming domain Rust is trying to work in. I frankly cannot understand why people are so willing to throw the baby out with the bathwater when it comes to Rust safety. It makes no sense to me to say "my code needs to have some % unsafe, so I'll just make it 100% unsafe then" (which is effectively what one does when they use C or C++ instead). Why insist on not taking any safety gains at all when one can't have 100% gain?
        uecker 1y ago
        The fallacy is believing that C / C++ code is 100% unsafe. Yes, Rust propaganda repeats this over and over but a good abstraction in C / C++ will also give you good safety properties. The safe Rust code over gnarly unsafe Rust code is only a little bit better than a nice C / C++ abstraction over gnarly code.
        1y ago
  - sunshowers 1y ago
    I agree in general Rust makes you use arrays and indexes, but heaps are traditionally implemented that way in any language.
- atemerev 1y ago
  We have to do arbitrary insertions/deletions from the middle, many of them. I think it is more like BTreeMap, but we need either sorting direction or rev(), and there were some problems with both approaches I tried to solve, but eventually gave up.
  - sunshowers 1y ago
    I see! The big issue I've run into with BTreeMap is that you can't provide an external comparator. If comparisons only require data that the keys already have, then the Reverse wrapper [1] has worked well for me. [1] https://doc.rust-lang.org/std/cmp/struct.Reverse.html https://doc.rust-lang.org/std/cmp/struct.Reverse.html
hacker_homie 1y ago
I have run into similar issues trying to build real applications. You end up spending more time arguing with the borrow checker than writing code.
- lytedev 1y ago
  I think this is true initially and Rust didn't "click" for me for a long time. But once you are _maintaining_ applications, man it really does feel like absolute magic. It's amazing how worry-free it feels in many respects. Plus, once you do embrace it, become familiar, and start forward-thinking about these things, especially in areas that aren't every-nanosecond-counts performance-wise and can simply `Arc<>` and `.clone()` where you need to, it is really quite lovely and you do dramatically less fighting. Rust is still missing a lot of features that other more-modern languages have, no doubt, but it's been a great ride in my experience.
  - skippyboxedhero 1y ago
    Using reference counts is a real issue. The idea with Rust is that you get safety...not that you get safety at the cost of performance. The language forces you into paying a performance cost for using patterns when it is relatively easy for a human to reason about safety (imo). You can use `unsafe` but you naturally ask yourself why I am using Rust (not rational, but true). You can use lifetimes but, personally, every time I have tried to use them I haven't been able to indicate to the compiler that my code is actually safe. In particular, the protections for double-free and free before use are extremely limiting, and it is possible to reason about these particular bugs in other ways (i.e. defer in Go and Zig) in a way that doesn't force you to change the way you code. Rust is good in many ways but the specific problem mentioned at the top of this chain is a big issue. Just saying: don't use this type of data structure unless you pay performance cost isn't an actual solution to the problem. The problem with Rust is that it tries to force safety but doesn't have good ways for devs to tell the compiler code is safe...that is a fundamental weakness. I use Rust quite a bit, it isn't a terrible language and is worth learning but these are big issues. I would have reservations using the language in my own company, rather than someone else's, and if I need to manage memory then I would look elsewhere atm. Due to the size of the community, it is very hard not to use Rust too (for example, Zig is great...but no-one uses it).
0x1ceb00da 1y ago
> Borrow checker killed me. You gotta get your timing right. Right hook followed by kidney shot works every time.
kelnos 1y ago
The nice thing is that you can always drop down to unsafe and use raw pointers if your data structure is truly not suited to Rust's ownership rules. And while unsafe Rust does have some gotchas that vanilla modern C++ does not, I would much rather have a 99% memory-safe code base in Rust than a 100% "who knows" code base in C++.
- atemerev 1y ago
  I have read the "too many linked lists" story and I think the other commenters here are right; the less pointers the better. Even with unsafe, there's just too much ceremony.

sunshowers 1y ago

I apologize for the naive question, but that sounds like a heap?

jpc0 1y ago
In my experience you need to approach this with vec or arrays of some sort and pass indices around… “We have pointers at home” behaviour. This is fine but coming from C++ it definitely feels weird…
- bigstrat2003 1y ago
  Why not just use pointers? Rust has them, they aren't evil or anything. If you need to make a data structure that isn't feasible with references due to the borrow checker (such as a linked list), there's absolutely nothing wrong with using pointers.
  - atemerev 1y ago
    And it will look like this: https://rust-unofficial.github.io/too-many-lists/sixth-final.html https://rust-unofficial.github.io/too-many-lists/sixth-final... (filled with boilerplate, strange Rust idioms, borrow_unchecked, phantomdata, and you still have to manage lifetimes annotations).
    - bigstrat2003 1y ago
      And? I don't really see the issue. It works, it is sound, and it has a nice clean interface for safe code to use. That's all I really ask for. Lots of useful things in programming are quite gnarly under the hood, but that doesn't mean those things aren't worth using.
      - uecker 1y ago
        It is fine, there is just not much Rust safety advantage left then. Also in C/C++ the errors do not usually occur when using a nicely defined API, but when doing the low-level gnarly stuff and getting it wrong. As said before, I think there is some advantage of Rust having a safe and unsafe subset, but is is nowhere as big as people claim it is.
        bigstrat2003 1y ago
        > It is fine, there is just not much Rust safety advantage left then. There's exactly as much as there was before though. The entire point of the Rust safety paradigm is that you can guarantee that unsafe code is confined to only where it is needed. Nobody ever promised "you will never have to write unsafe code", because that would be clearly unfeasible for the systems programming domain Rust is trying to work in. I frankly cannot understand why people are so willing to throw the baby out with the bathwater when it comes to Rust safety. It makes no sense to me to say "my code needs to have some % unsafe, so I'll just make it 100% unsafe then" (which is effectively what one does when they use C or C++ instead). Why insist on not taking any safety gains at all when one can't have 100% gain?
        uecker 1y ago
        The fallacy is believing that C / C++ code is 100% unsafe. Yes, Rust propaganda repeats this over and over but a good abstraction in C / C++ will also give you good safety properties. The safe Rust code over gnarly unsafe Rust code is only a little bit better than a nice C / C++ abstraction over gnarly code.
        1y ago
- sunshowers 1y ago
  I agree in general Rust makes you use arrays and indexes, but heaps are traditionally implemented that way in any language.
atemerev 1y ago
We have to do arbitrary insertions/deletions from the middle, many of them. I think it is more like BTreeMap, but we need either sorting direction or rev(), and there were some problems with both approaches I tried to solve, but eventually gave up.
- sunshowers 1y ago
  I see! The big issue I've run into with BTreeMap is that you can't provide an external comparator. If comparisons only require data that the keys already have, then the Reverse wrapper [1] has worked well for me. [1] https://doc.rust-lang.org/std/cmp/struct.Reverse.html https://doc.rust-lang.org/std/cmp/struct.Reverse.html

hacker_homie 1y ago

I have run into similar issues trying to build real applications. You end up spending more time arguing with the borrow checker than writing code.

lytedev 1y ago
I think this is true initially and Rust didn't "click" for me for a long time. But once you are _maintaining_ applications, man it really does feel like absolute magic. It's amazing how worry-free it feels in many respects. Plus, once you do embrace it, become familiar, and start forward-thinking about these things, especially in areas that aren't every-nanosecond-counts performance-wise and can simply `Arc<>` and `.clone()` where you need to, it is really quite lovely and you do dramatically less fighting. Rust is still missing a lot of features that other more-modern languages have, no doubt, but it's been a great ride in my experience.
- skippyboxedhero 1y ago
  Using reference counts is a real issue. The idea with Rust is that you get safety...not that you get safety at the cost of performance. The language forces you into paying a performance cost for using patterns when it is relatively easy for a human to reason about safety (imo). You can use `unsafe` but you naturally ask yourself why I am using Rust (not rational, but true). You can use lifetimes but, personally, every time I have tried to use them I haven't been able to indicate to the compiler that my code is actually safe. In particular, the protections for double-free and free before use are extremely limiting, and it is possible to reason about these particular bugs in other ways (i.e. defer in Go and Zig) in a way that doesn't force you to change the way you code. Rust is good in many ways but the specific problem mentioned at the top of this chain is a big issue. Just saying: don't use this type of data structure unless you pay performance cost isn't an actual solution to the problem. The problem with Rust is that it tries to force safety but doesn't have good ways for devs to tell the compiler code is safe...that is a fundamental weakness. I use Rust quite a bit, it isn't a terrible language and is worth learning but these are big issues. I would have reservations using the language in my own company, rather than someone else's, and if I need to manage memory then I would look elsewhere atm. Due to the size of the community, it is very hard not to use Rust too (for example, Zig is great...but no-one uses it).

0x1ceb00da 1y ago

> Borrow checker killed me. You gotta get your timing right. Right hook followed by kidney shot works every time.

kelnos 1y ago

The nice thing is that you can always drop down to unsafe and use raw pointers if your data structure is truly not suited to Rust's ownership rules. And while unsafe Rust does have some gotchas that vanilla modern C++ does not, I would much rather have a 99% memory-safe code base in Rust than a 100% "who knows" code base in C++.

atemerev 1y ago
I have read the "too many linked lists" story and I think the other commenters here are right; the less pointers the better. Even with unsafe, there's just too much ceremony.