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

141–150 of 283 posts

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

#141

Post by ilovecaching »

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’ve had the opposite experience. Type driven development makes writing code easier, with less errors, and also makes refactoring significantly easier. For those of us where C++ is the optimal choice Rust is a major step forward in terms of better abstraction, safety, and yet maintains the efficiency requirements we need.

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

#142

Post by raphlinus »

dahfizz wrote: post #111
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 have started to see a worrying trend were developers focus more on how easy it is to develop X rather than how good of a finished product is X. It makes sense for developers to want development to be easier and for businesses to want it to be faster but it feels lazy and cheap to actively avoid tools that would help us produce better programs with much stronger guarantees in the name of ease of development. It's no…

This. I believe the value proposition of Rust is that it decreases the cost of developing high quality software, much as the value proposition of PHP is that it decreases the cost of medium-quality software. It is not a magic bullet, but requires a nontrivial learning curve. If the goal is safe, performant code, then I think there's a good argument it's worth it. If that's not the goal, then other languages might be better choices.

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

#143

Post by Retra »

hawski wrote: post #59
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…

You're assuming those checks are a real bottleneck for compile times. Rust only does borrow checking at the function level, so it's easy to parallelize and not all that slow. Most of the compile time is spent on code gen, if I recall correctly.

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

#144

Post by alexnewman »

I was a fan of rust when it first started. i wrote some consensus algorithms and metrics packages in rust. i also hosted a rust podcast. I now believe Rust has failed. Mostly because of the arrogance of organizations like the rust community and the inability to form stronger relationships with companies like apple. I now think that people should focus on swift and soon it will have the same native code support and a borrow checker. I think we all learned a lot but it’s time to realize people still don’t understand why not go and swift. C programmers continue to prefer c and more and more people are shifting back from rust to c++. rust will never provide enough

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

#145

Post by mcguire »

"When you implement an algorithm using C++, you can write it down without one second of pause, but you can’t do that in Rust. As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving."

Yeah...

On my last C++ project, one very productive co-worker kept disabling -Wall, etc., because "nobody has got time for that." I periodically fired up valgrind and chased down assorted memory issues.

So, yeah...

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

#146

Post by Retra »

mrfredward wrote: post #135
nicoburns wrote: post #118

Earlier quoted context omitted.

Actually, a lot of the issues that C/C++ programmers have when they are new to Rust seem to be precisely because idiomatic Rust code (which can help to avoid borrow checker issues) is often in a more functional Scheme/OCaml style. Rust is both algol-derived, and ocaml-derived. And arguably the borrow checker creates a new paradigm entirely.

>The borrow checker creates a new paradigm entirely I don't think this can be emphasized enough. You can get deceivingly far in rust with an OOP style, only to come to the disheartening conclusion that it's impossible to do what you want with the architecture you spent months of work setting up. For example, how would you architect a simple single threaded emulator? The CPU is an object, RAM is an object, easy enough…

It is hard to think about program architecture. Most languages don't make you think about it at all, they just let you jam code together however you want and give you the tools to make it work.

That was the biggest shock I had moving to Rust: I couldn't just do what I wanted, I had to figure out how to do what Rust wanted. But I also wanted to learn how to design systems better, so the fact that Rust makes me think deeper about it is an advantage for me. In an OO language, I'd just lazily cobble things together. The code would work, but I would learn nothing.

And some people would rather do things that way. It is very hard to break habits, and Rust basically forces you to do that.

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

#147

Post by shepmaster »

mrfredward wrote: post #137
ilovecaching wrote: post #134

Three problems with this: 1. You still have to fight with borrow checking in Rust as in C++, it’s just not automated. You have to consider moves and copies, borrowed references, etc. As the author points out, if you’re used to writing C or C++, it’s going to take a while before responding to the borrow checker is second nature. The point is that the borrow checker is a computer and doesn’t make mistakes the same way…

>You still have to fight with borrow checking in Rust as in C++, it’s just not automated. It's not that easy. The borrow checker gives you memory safety and thread-safety. In C++, you always have to worry about memory safety, so here the ownership model and borrow checker is a pure win. However, in C++ you don't have to worry about thread safety in a single thread...there's no barrier to passing pointers around and m…

My counter argument is nicely summed up by The Problem With Single-threaded Shared Mutability (https://manishearth.github.io/blog/2015/05/17/the-problem-wi...)

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

#148

Post by htfy96 »

mrfredward wrote: post #137
ilovecaching wrote: post #134

Three problems with this: 1. You still have to fight with borrow checking in Rust as in C++, it’s just not automated. You have to consider moves and copies, borrowed references, etc. As the author points out, if you’re used to writing C or C++, it’s going to take a while before responding to the borrow checker is second nature. The point is that the borrow checker is a computer and doesn’t make mistakes the same way…

>You still have to fight with borrow checking in Rust as in C++, it’s just not automated. It's not that easy. The borrow checker gives you memory safety and thread-safety. In C++, you always have to worry about memory safety, so here the ownership model and borrow checker is a pure win. However, in C++ you don't have to worry about thread safety in a single thread...there's no barrier to passing pointers around and m…

Another issue is that in real world types in fast programs usually can't be expressed and auto checked by a simple type system without mental/runtime overhead. For example, in many GPU kernels each thread visits patterns like (ax+b)%k, how do you ensure no data race in this example? The result depends on the coprimality between a and k. You will still need to check this at runtime and creating affine_mod_view for each access patterns like this would be overkill.

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

#149

Post by ksec »

coldtea wrote: post #79
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…

> However, the author is still someone who does not know how to use a programming language and is still bound to not only the mental model of another programming language but also bad practices that lead to problems. Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code. Now it's applied to the other side (…

>Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code.

I have yet to see anyone jump to Rust on first try and fell in love or could immediately use it in production with no problem. There is a huge learning curve involves.

More than often, ( Or pretty much in every case ) They gave up. It was way too complex, they hated it, it was the first time they actually had to "fight" the compiler just to get shxt done.

And then somehow after 3 / 6 / 12 / 24 months later. On 2nd try it clicked.

It wasn't just Rust 1.0 or Rust 1.2 being harder, and the newest version being easier. It is just, dare I say Human Nature? Or you have been learning Rust in your background thread for few months without you even realising it. And once it clicked, everything you hate about it seems to be God Send to programming and software development.

For a lot of people they may never click, after all Borrow Checked is complex and hard.

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

#150

Post by pjmlp »

gmueckl wrote: post #64
jayd16 wrote: post #56

Earlier quoted context omitted.

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.

Unity makes it very clear in their blog posts that Burst is a special vectorizing compiler. It is not a linter at all. I am not sure where you got that notion. IL2CPP was required to be able to stick with C# and stay relevant for mobile gaming. They forced themselves into this corner by wanting to stay with C# and become relevant for mobile gaming. Compare all this to Unreal. By sticking to C++, they do not have to c…

Actually they do, because Blueprints need to support graphical debugging and profiling as well.

Some studios don't want to mess that much with Unreal's C++.

Then Unreal has their own C++ runtime to allow for a tracing GC.

Post reply on HN