Matt Godbolt sold me on Rust by showing me C++

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.

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

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.

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…

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.

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.

> Borrow checker killed me.

You gotta get your timing right. Right hook followed by kidney shot works every time.

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).

The idea with rust is that you _can_ have safety with no performance cost if you need it, but depending on what you're building, of course, that may imply extra work.

The pragmatism of Rust means that you can use reference counting if it suits your use case.

Unsafe also doesn't mean throwing out the Rustiness of Rust, but others have written more extensively about that and I have no personal experience with it.

> 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.

My understanding is that this is the purpose of unsafe, but again, I can't argue against these points from a standpoint of experience, having stuck pretty strictly to safe Rust.

Definitely agree that there are issues with the language, no argument there! So do the maintainers!

> if I need to manage memory then I would look elsewhere atm

Haha I have the exact opposite feeling! I wouldn't try to manage memory any other way, and I'm guessing it's because memory management is more intuitive and well understood by you than by me. I'm lazy and very much like having the compiler do the bulk of the thinking for me. I'm also happy that Rust allows for folks like me to pay a little performance cost and do things a little bit easier while maintaining correctness. For the turbo-coders out there that want the speed and the correctness, Rust has the capability, but depending on your use case (like linked lists) it can definitely be more difficult to express correctness to the compiler.

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++.

I agree in general Rust makes you use arrays and indexes, but heaps are traditionally implemented that way in any language.

Agree, that is the purpose of unsafe but there is a degree of irrationality there, which I am guilty of, about using unsafe in Rust. I also worry about unsafe leaking if I am using raw pointer on a struct...but stdlib uses a lot of unsafe code, so I should be too.

I think the issue that people have is that they come into Rust with the expectation that these problems are actually solved. As I said, it would be nice if lifetimes weren't so impossible to use.

The compiler isn't doing the thinking if you have to change your code so the compiler is happy. The problem with Rust is too much thinking: you try something, compiler complains, what is the issue here, can i try this, still complain, what about this, etc. There are specific categories of bugs that Rust is trying to fix that don't require the changes that Rust requires in order to ensure correctness...if you use reference counter, you can have more bugs.

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.

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).

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.

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

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.

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.

> 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?

Is there a safety advantage to using Java given that the HotSpot JVM is written in C++?

All safe code is built on a foundation of unsafe code.

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.

Sure, but the point is that you can also build reasonably safe abstractions in C / C++.

The last fifty years have shown us that you can't — at least not sustainably and at scale. You can do so at one moment in time, or for smaller projects, but not in the face of large scale projects with team members changing over time.

I don't this the last fifty years show this at all, although Rust proponents want you to believe this.

I guess.