Rust is still completely unusable as you can't use dynamic linking as there's no stable ABI.
Why I rewrote the mesh generator of Dust3D from Rust to C++
41–50 of 283 posts
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#42The 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.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#43Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#44Earlier 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.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#45The 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.
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++
#46Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#47Earlier 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.
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++
#48Doing 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.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#49The 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…
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++
#50Earlier 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 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.