Live data from Hacker News

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

blogs.dust3d.org

41–50 of 283 posts

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

#41

Rust is still completely unusable as you can't use dynamic linking as there's no stable ABI.

Rust supports stable ABI with extern C. I agree it is highly suboptimal, but it works well enough that there are multiple production Redis modules entirely written in Rust, for example.

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

#42
post #6

The first few comments here seem to argue against the article, as do comments below the post but I am very much with the author. I strongly disagree with the Rust mentality, and the general mentality of statically typed languages with extremely prohibitive compile time checks, that seem to become more common. Underlying that model seems to be a concept of software like a sort of renaissance master's marble statue, er…

> capacity to change Good luck making changes to a 100kloc Python codebase.

No problem. I do it every day.

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

#44
post #39

Earlier quoted context omitted.

> Need is relative. If you can get the extra speed, why waste it? Because you can be a lot more productive if you are not extremely constrained by speed.

That’s a false dichotomy. A language can be both productive and fast.

In theory, yes. In practice, Rust at the moment is less productive than GC languages. I am hoping for autoclone mode in the future (sort of like Swift ARC).

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

#45
post #13
post #6

The first few comments here seem to argue against the article, as do comments below the post but I am very much with the author. I strongly disagree with the Rust mentality, and the general mentality of statically typed languages with extremely prohibitive compile time checks, that seem to become more common. Underlying that model seems to be a concept of software like a sort of renaissance master's marble statue, er…

This was my impression as well when I tried Rust - always fighting the compiler. None of this happens with D. You just code away and keep being productive without the annoyances of C++. In fact C++11 and 17 are less and less annoying.

Fighting which stops eventually. I program Rust for nearly a year now and I found that there is a point where it gets quite smooth. The many mental guarantees that the code gives you can help you a lot to stop worrying about a whole class of things. I realized just how much this is the case when I wrote something in Python again and separation of which code affects what and which code is doomed to fail from the start became much harder.

Rust initially has been a lot about fighting the borrow checker, but once you get the hang of it it happens quite often that you write pages of a complex functionality including tests – you hit build and it just works.

I am certain that Rust prevents entire classes of problems I filed bug reports for, even with extremely experienced developers. I understand that the nagging voice of the compiler or cargo clippy is not just for everyone, tho.

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

#46
I wonder how many of the Rust defenders in this article actually know C++ and have written a production used Rust system, instead of a side-project on github, so that they can compare in an informed way? The author certainly has, but who else has? Step forth priests of Rust! As for me: I use C++ at my job daily but have never done Rust so I cannot compare. What I do know about is "memory safety" in C++, and to be honest, the tools available are enough to make you figure out any issue: gdb/core dumps/valgrind, when combined with good software practices and unit tests seem to work ok for the rest of us. The compilers now have sanitizers, and new versions of gcc actually tell you what your template errors are. It's 2019, not 2005 for C++. Smart pointers are now available: use them! Finally, if a Rust veteran could let me know: how does Rust deal with general resource management in the presence of exceptions? Not everything a program uses is memory: we sometimes need sockets! In C++ using RAII works well, does the Rust Type System statically error/type check non-memory resources automatically, or is that out of scope?

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

#47
post #36
post #26

Earlier quoted context omitted.

Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.

> Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough. Meshing software is a typical program where you need C++ and where Java is a terrible choice. By nature, meshing makes you play with millions to billions of very small object with mutual interactions. A thing that Java GC absolutely hate. Sorry for the Java fan-boys.

The billion vertex objects might be a nice torture test benchmark for a gc or malloc implementation, but fortunately things aren't so grim in the real world:

Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC.

In some algorithms, other data structures such as trees, may be used used as intermediate formats, but there too the options to use malloc/gc allocated nodes vs alternatives is similar in a GC'd vs a non-GC'd language.

In general, good GC's often outperform malloc/free. Because GC's are amenable to parallelization in the background, and because malloc/free don't enjoy the bump-allocator style happy case that is used in generational GC's nursery objects.

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

#48
post #27
post #12

Doing game dev and digital content creation in anything but C++ and some python is simply a fool's errand. Any decent software in this area needs to use libraries written in C++ to have even a remote chance of being successful. These libraries are often written in ways that makes wrapping them for other languages impossible or at least force the exclusion of some desirable features in the bindings. In other words, C+…

Unity, one of the most popular engines out there, is mainly about C# for the gamedevs.

And it is a special snowflake because of that. Unity needs to pour a ton of resources into this to make it viable and competitive. IL2CPP and the Burst compiler are proof. A company with fewer resources would have to give up on this approach.

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

#49
post #6

The first few comments here seem to argue against the article, as do comments below the post but I am very much with the author. I strongly disagree with the Rust mentality, and the general mentality of statically typed languages with extremely prohibitive compile time checks, that seem to become more common. Underlying that model seems to be a concept of software like a sort of renaissance master's marble statue, er…

Its just temporary pain. Once you learn to use types properly, you stop having to constantly think about typing. I assume Rust pointer ownership is much the same way.

The author was doing unsafe stuff and the compiler complaining. Once he gets in the swing of things, doing it right will become his natural flow. Verbosity of a language is a valid complaint that never goes away no matter how idiomatic your code writing gets but as written I'm not sure this was the author's complaint.

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

#50
post #36
post #26

Earlier quoted context omitted.

Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.

> Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough. Meshing software is a typical program where you need C++ and where Java is a terrible choice. By nature, meshing makes you play with millions to billions of very small object with mutual interactions. A thing that Java GC absolutely hate. Sorry for the Java fan-boys.

I have to second this. I tried to write a 3d modelling tool in Java. I got decent, but not stellar performance only once I consciously started to fight the GC in my code.

I converted that code to C++ and recently added a custom allocator to improve performance even further. The result is now functionally equivalent, but about 5 times faster.

Post reply on HN