←back to thread

611 points LorenDB | 1 comments | | HN request time: 0.001s | source
Show context
atemerev ◴[] No.43908259[source]
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.

replies(4): >>43908277 #>>43908709 #>>43909131 #>>43909428 #
sunshowers ◴[] No.43908277[source]
I apologize for the naive question, but that sounds like a heap?
replies(2): >>43908888 #>>43910095 #
jpc0 ◴[] No.43908888[source]
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…
replies(2): >>43908917 #>>43909512 #
bigstrat2003 ◴[] No.43908917{3}[source]
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.
replies(1): >>43910054 #
atemerev ◴[] No.43910054{4}[source]
And it will look like this: 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).

replies(1): >>43910962 #
bigstrat2003 ◴[] No.43910962{5}[source]
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.
replies(1): >>43913004 #
uecker ◴[] No.43913004{6}[source]
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.
replies(2): >>43918304 #>>43918558 #
bigstrat2003 ◴[] No.43918304{7}[source]
> 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?

replies(1): >>43921929 #
1. uecker ◴[] No.43921929{8}[source]
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.