Why I rewrote the mesh generator of Dust3D from Rust to C++ • Hacker News Board

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

#51

Post by atoav » Fri, Mar 15, 2019, 7:43 AM UTC

Barrin92 wrote: 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…

I am probably more of a beginner when it comes to compiled languages. What surprised me most about Rust was that after understanding it, I liked it more than Python. I intended to learn it as a speedier more controlled alternative. A sharp tool to throw at slow code to make it go away.

But once I got the hang of it progtamming Python became less and less attractive. The most interesting thing about rust is, how fast you can get up to speed with understanding what somebody elses code does.

The thing however is: if you try to write Rust like Python or C, you’re not in for a good time. It took me 3 months to stop using ingrained OOP patterns I really thought I needed because this was the way how I did things back in Python.

The moment I started to become interested into how to structure code in Rust, was the moment it made click for me. Seems it is much easier to program WITH the compiler than against it — who would have known!

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

#52

Post by stunt » Fri, Mar 15, 2019, 7:44 AM UTC

Barrin92 wrote: 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…

That’s not necessarily a fair point to compare. Perhaps it just feels like that because C++ has been around for a long time. If you write production code without being a C++ master, you also have different struggles before getting it right.

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

#53

Post by sanxiyn » Fri, Mar 15, 2019, 7:44 AM UTC

gcc_programmer wrote: post #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 hon…

I can. I (well, it's the team effort, so we) rewrote production system written in C++ with Rust. Even before the rewrite, C++ codebase was in modern C++17.

Re: general resource management. It works exactly the same. Rust also does RAII. Rust also doesn't use exceptions for error handling.

One easy to state advantage of Rust over C++ is that it checks your threading design.

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

#54

Post by gmueckl » Fri, Mar 15, 2019, 7:46 AM UTC

fulafel wrote: post #47

adev_ wrote: post #36

Earlier quoted context omitted.

> 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 st…

I never met a GC that can deal with millions of allocations per second while having several millions of objects in the young generations. Some mesh processing algorithms have a tendency to get you there very quickly if you do not employ custom allocators. At this point you already defeated the GC provided by the language.

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

#55

Post by devwastaken » Fri, Mar 15, 2019, 7:52 AM UTC

Barrin92 wrote: 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…

Rust doesn't make much sense for this kind of project in the first place. You use it for things that need to be memory correct, and proveably so. Very useful for handling uncontrolled data.

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

#56

Post by jayd16 » Fri, Mar 15, 2019, 7:52 AM UTC

gmueckl wrote: post #48

est31 wrote: post #27

Earlier quoted context omitted.

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.

Mono runs fine. IL2CPP is more of a work around to get AOT on iOS and Burst is just a nice linter but you could write the same tight loops now and mostly likely get very close. Plus, Burst isn't even out so its odd to bring it up as necessary.

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

#57

Post by pizza234 » Fri, Mar 15, 2019, 7:54 AM UTC

adamnemecek wrote: post #10

Barrin92 wrote: 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.

I do something similar daily, and it works fine, as we have a strong test suite.

You can't disassociate dynamically typed languages from (strong) test suites, so one needs to qualify:

> Good luck making changes to a 100kloc Python codebase without test suite

versus

> Good luck making changes to a 100kloc Python codebase with a good test suite

In context, the first case is no different from "Good lucking making changes to a 100kloc Rust spaghetti-coded codebase", and one can't meaningfully judge a something based on a poor use of it.

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

#58

Post by fulafel » Fri, Mar 15, 2019, 7:55 AM UTC

gmueckl wrote: post #54

fulafel wrote: post #47

Earlier quoted context omitted.

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 st…

I never met a GC that can deal with millions of allocations per second while having several millions of objects in the young generations. Some mesh processing algorithms have a tendency to get you there very quickly if you do not employ custom allocators. At this point you already defeated the GC provided by the language.

You would have to be dealing with a very large number of meshes at once, if you were churning through millions of vertex and uv arrays per second. I can't say what you should use in this scneario. But this is a pretty niche scenario! And you would probably want to focus on parallelism, where C++ again is not the best.

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

#59

Post by hawski » Fri, Mar 15, 2019, 7:56 AM UTC

Barrin92 wrote: 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…

There could be a --i-am-a-stuntman-and-i-spit-in-the-face-of-danger flag, that would disable some checks for compilation to be fast enough. It could be used when building known good packages or during design iteration. It would be an escape hatch.

Of course the problem is: would people just add the flag to their configuration and never disable it? I think they would not. Because people mostly use defaults. That's why instead of -Wall -Wextra -pedantic with possible -Wereor for development, most places I worked in ignore most default warnings and just occasionally run some kind of static analysis. Even though many times the analysis often results with things that would be detected with additional warning flags.

And yeah I hate it and I wish that warnings would mostly be treated as errors or silenced when applicable. Then there are always separate efforts to "clean the warnings". But afterwards new code just introduces new warnings, because people are trained to ignore them.

I assume that Rust developers don't want my scenario to happen at all, but I feel that with defaults reversed it wouldn't.

But maybe it's to great a risk? Of course as always it's a game of trade offs.

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

#60

Post by tsimionescu » Fri, Mar 15, 2019, 7:57 AM UTC

geezerjay wrote: post #34

Barrin92 wrote: 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…

> The downside that the author points out seem to be often neglected. Constant interruption and battling with the type system during development, when mental overhead is a problem. This assertion is just wrong. The author makes it quite clear that he doesn't know the language and is still taking his first steps ( "I am still a Rust learner, not a veteran" ), he implies that has problems with correct memory management…

> Heck, the author praises Rust and it's memory safety, but then proceeds to criticise Rust compiler because, as he puts it, the compiler will stop you from doing unsafe studf again and again. Isn't that the whole point? Or is anyone expecting that your memory corruption problems will magically cease because you write your same old memory allocation and access bugs in Rust instead of C or C++?

I think the biggest problem with advanced type systems and complex compiler checks is that they are only desirable when you know the code you're writing is the the right one. A lot of the time, you're exploring a solution and don't care about edge cases, since you're not sure you've even found the right happy path. At this stage, you don't really care if your code is handling all required inputs, if it doesn't have leaks etc. - you just want to run it and see whether it at least sometimes produces the right output. At this stage, you're often fighting the compiler.

Once you know that you're on a good path, then you start caring about safety and all the other bits, and the compiler starts becoming a trusted friend.

It would be really interesting to have a system that supported both modes, e.g. starting from Rust but setting a flag to turn borrow checker errors into warnings or something similar. I'd bet that would change many people's perspectives, like the author of this article.