Why I rewrote the mesh generator of Dust3D from Rust to C++ · Dust3D


#1

Dust3D is a quick 3D modeling software. It automatically generates a mesh from nodes drawn by the user. Most of the code is implemented in C++ with Qt, including the UV unwrapper, rigger, pose and motion editor etc, however, the core mesh algorithm was written in Rust. Recently I have rewritten the Rust part. The codebase is pure C++ now.


This is a companion discussion topic for the original entry at https://blogs.dust3d.org/2019/03/13/why-i-rewrote-the-mesh-generator-of-dust3d-from-rust-to-cplusplus/

#2

the hardship is supposed to enable correct code, no? imagine a compiler that is able to check thread safe code, i would be worried if its saying I’m doing the wrong thing. my only experience is with Go where it can know that every thread is aslep.


#3

So, pretty much the conclusion is: “I didn’t learn Rust enough so I got back to struggle with what I know…”

Even when you say Rust has what you need, you stubbornly tried to fight it back… Mhmm…

OK… Got it…

Rust encourages code correctness, prevents you from having mem leaks here and there and you pretty much say all the marvels that it offers you get in your way… Ooof.


#5

Let’s not be dogmatic here. I applaud the virtues of Rust and am all for static safety. That being said, Rust is not a panacea, nor a one-size-fits-all solution that can be levied against any problem.

As an example of a class of problems where I’ve struggled with Rust - cyclic data structures. I would encourage everyone to try implementing their own binary search tree in Rust (and not using an array representation!). I don’t believe a solution is possible using plain lifetimes. Using Rc<RefCell<T>> quickly becomes tedious with all the cumbersome type annotations, dereferencing, and unwrapping, and even then your program can still panic at runtime if you don’t borrow_mut carefully! What happened to all the static guarantees?

At what point do you just step down into unsafe Rust and munge around pointers? When I got to this point I just started asking myself why I decided not to write this in plain C.

Ultimately, like everything else, the choice of Rust has its associated benefits and drawbacks. Sometimes code just needs to be shipped out the door, at the expense of memory safety and getting off the Rust bandwagon. This is a tradeoff, and the author of this post seems to have put careful thought into their choice of solution.


#6

Why not ask some more experienced Rust people for help? Just off the top of my head: for example the guy that is working on the Plexus crate?

That way you keep the existing code, can bump your Rust skills by seeing how a more experienced Rust developr implements /your/ algorithm(s) and still drive the whole thing.


#7

Why not to just use raw pointers in Rust?


#8

When you implement an algorithm using C++, you can write it down without one second of pause,

Sorry, I cannot, because of so many things to worry about.

you can’t do that in Rust.

But I can. I will just use unsafe pointers to get job done, like in C or C++, then I will wrap unsafe code in safe interface.


#9

But, there is no Qt

no CGAL

Creating binding for C libraries is easy (just use crust). Bindings for C++ is complicated, because C++ has it own runtime, but solvable problem with rithual.


#10

I think we’ll be seeing more and more Rust posts like this. Somewhere in the future someone will invent a new language based on some of the ideas of Rust, and make it much more productive. Until then, it’s just too painful.


#11

Then don’t? I think Rustaceans, and people who are attracted to Rust, are perfectly happy to make sacrifices if it means code correctness.
But I still don’t understand this weird requirements, “what if I WANT to make memory leak huh?? can you language do that?” is just dumb and unproductive