Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blogs.dust3d.org

Post reply on HN
Print view View original

81–90 of 283 posts

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

#81

Post by gmueckl »

fulafel wrote: post #75
gmueckl wrote: post #69

Earlier quoted context omitted.

Thia is true only if you have the foresight to write custom allocators. Unless you limit possible mesh topologies, you must deal with many tiny arrays for each vertex, edge and face and their lengths are not uniform.

Yes, depending on what you mean by custom allocator... but this is the same in C++ too, right? To store custom vertex / face attributes, you can use a variety of sparse techniques to save memory from sitting unused in attribute arrays. Basically you want an interface of get_attribute(type, vertex_id). This sparse matrix, trie, or whatever can be backed by int or float array storage instead of many many tiny malloc'd/…

Yes, these backing constructs essentially become special case memory managers for the problem domain. You may call then by different names, but the essential behaviour is the same.

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

#82

Post by gmueckl »

pjmlp wrote: post #71
gmueckl wrote: post #48

Earlier quoted context omitted.

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.

The same was said about the game developers using Pascal and C instead of Assembly, followed by game developers using C++ instead of C. The industry always needs some pioniers willing to do the investment regardless of the naysayers.

I am not a naysayer. I just point out the resource investment involved in going down a different path.

Also, Unity is built on a lot of 3rd party C++ code. From the top of my head, this is at least Mono, FMOD, PhysX, Enlighten and FBX.

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

#83

Post by blub »

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…

That's a decent attempt at suppressing OP's message, but the thing which makes all of the above irrelevant is that C and C++ developers are the main groups of developers Rust is targeting.

If they can't use the language, the Rust community should perhaps listen to them. Or should have listened to them 10 years ago, because let's be frank: the friction is coming from the fact that Rust can't be changed any more so that it becomes as ergonomic as other languages people are used to. It's also moved heavily in the direction of some FP concepts which have zero overlap with C and arguably little to do with C++.

The big assumption Rust is based on is that people will recognise the benefits of memory safety and be willing to pay the price for it. Many outside the early adopter group won't be, that's how the mainstream works.

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

#84

Post by Const-me »

isatty wrote: post #20
petre wrote: post #13

Earlier quoted context omitted.

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.

I believe you’ve not been on the receiving end of a 17 page compiler error while trying to compile a template heavy app, because you forgot to put an &. The important part is to realize _why_ you’re fighting the compiler as it’s trying to make _you_ write better code and improve. If you find non issues being reported by the compiler please report it and make it better for all of us too!

> as it’s trying to make _you_ write better code and improve.

It’s not necessarily an improvement. When an algorithm processes complex data structures organized in graph or tree, no amount of better code allows to easily implement that in Rust. It’s either slow, or unsafe and hard to implement, or both.

Even without trees, consider a simple LRU cache structure. Trivial to implement in most languages by combining linked list with hash map. Rust implementation is more than 1000 lines of code, many of them are unsafe: https://docs.rs/linked-hash-map/0.4.2/src/linked_hash_map/li...

I never wrote production code in Rust. But based on my limited experience, the language is fine for projects that have few data structures, or they’re simple so you can stick to library containers, and a lot of code processing them. For many practical problems it’s quite the opposite.

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

#85

Post by pjmlp »

gmueckl wrote: post #82
pjmlp wrote: post #71

Earlier quoted context omitted.

The same was said about the game developers using Pascal and C instead of Assembly, followed by game developers using C++ instead of C. The industry always needs some pioniers willing to do the investment regardless of the naysayers.

I am not a naysayer. I just point out the resource investment involved in going down a different path. Also, Unity is built on a lot of 3rd party C++ code. From the top of my head, this is at least Mono, FMOD, PhysX, Enlighten and FBX.

Sure, just like those C and C++ engines weren't re-writing the battle proven Assembly libraries unless required to do so.

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

#86

Post by pjmlp »

gmueckl wrote: post #78
pjmlp wrote: post #72

Earlier quoted context omitted.

Time travel 20 years back on some USENET forum. "When a game seems to be written exclusively in a high level language like C++ then there is almost always a massive framework underneath that integrates a lot of shiny C and Assembly libraries for the real heavy lifting." Time travel 30 years back on some BBS forum. "When a game seems to be written exclusively in a high level language like C or Pascal then there is alm…

Except that games back then were limited in code size by what could be stored in memory on the target systems. All the game code that I have seen from the 80s and early 90s came in well under 100kloc and library dependencies weren't a thing because of the same resource constraints. This changed over time and now almost any contemporary and technically decent game sits on top of several hundreds of thousands or millio…

Sure and that 3rd party code can be written in whatever language the library authors feel like using, it doesn't need to be necessarly C or C++.

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

#87

Post by xvilka »

atoav wrote: post #51
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 try to use Elixir for scripting instead. It feels "right", after the experience with OCaml, Rust, and similar languages.

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

#88

Post by baq »

blub wrote: post #83
geezerjay wrote: post #34

Earlier quoted context omitted.

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

That's a decent attempt at suppressing OP's message, but the thing which makes all of the above irrelevant is that C and C++ developers are the main groups of developers Rust is targeting. If they can't use the language, the Rust community should perhaps listen to them. Or should have listened to them 10 years ago, because let's be frank: the friction is coming from the fact that Rust can't be changed any more so tha…

i'd say game developers aren't really the target audience, because they expect to move fast and not necessarily correct, just correct enough most of the time. other developers don't have issues with the compiler being more picky; compile times are more of a problem in adoption than language strictness.

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

#89

Post by baq »

Const-me wrote: post #84
isatty wrote: post #20

Earlier quoted context omitted.

I believe you’ve not been on the receiving end of a 17 page compiler error while trying to compile a template heavy app, because you forgot to put an &. The important part is to realize _why_ you’re fighting the compiler as it’s trying to make _you_ write better code and improve. If you find non issues being reported by the compiler please report it and make it better for all of us too!

> as it’s trying to make _you_ write better code and improve. It’s not necessarily an improvement. When an algorithm processes complex data structures organized in graph or tree, no amount of better code allows to easily implement that in Rust. It’s either slow, or unsafe and hard to implement, or both. Even without trees, consider a simple LRU cache structure. Trivial to implement in most languages by combining link…

> Even without trees, consider a simple LRU cache structure. Trivial to implement in most languages by combining linked list with hash map. Rust implementation is more than 1000 lines of code, many of them are unsafe: ...

in this context, criticizing using unsafe in rust and comparing that to C++ is comparing apples to oranges. GC languages aren't even worth mentioning here.

> It’s not necessarily an improvement. When an algorithm processes complex data structures organized in graph or tree, no amount of better code allows to easily implement that in Rust. It’s either slow, or unsafe and hard to implement, or both.

here's the thing: all of the above are true in other languages, C/C++ included, it's just that no compiler besides rust will warn you that recursive data structures are hard - it doesn't matter if implementing them is easy, proving they're implemented correctly never is. rust tries to help you prove you did the right thing and it needs assurances (unsafe) where it just can't do that. C++ is all unsafe.

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

#90

Post by p0nce »

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'm 100% with you.

There is often a debate in the D community how the defaults could have been better: pure, @safe, const by default, no GC by default etc.

But not every bit of code need to be perfect. Code must prove its usefulness first and foremost, before the need to be reliable, safe, fast and beautiful even enter the picture.

I'd go as far as to say, thinking of a nascent project as something perfect and beautiful likely leads to over-idealization and will delay the time to completion many-folds.

Ability to write ugly code is - for me - a feature.

Post reply on HN