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

91–100 of 283 posts

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

#91

Post by baq »

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.

did that on 50k code base with the help of runtime automatic type annotators (e.g.https://github.com/Instagram/MonkeyType) it's absolutely doable, it took a few days total.

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

#92

Post by gameswithgo »

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

your final assertion implies that any new language that is a significant paradigm shift from c++ must be flawed.

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

#94

Post by mewse »

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.

Note that the game industry avoided C++ for a long time because those early C++ compilers produced code which was very large and quite a lot slower than you'd get from C, so C++ was kind of a non-starter when you were writing code for the consoles of the day which had slow processors and only a few megabytes of RAM. You just couldn't afford the overheads of C++ or your competitors would eat your lunch.

It wasn't about needing a pioneer to show us that we'd been wrong; we weren't wrong. C++ just wasn't ready for the particular set of requirements that games imposed, yet. Once the state of C++ compilers began dramatically improving in the late 90s (by the criteria of optimisation and executable sizes), most studios moved over to the language pretty quick. Or at least that was my experience.

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

#95

Post by sametmax »

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 agree, but let's remember how young rust is, how little experience people have with it and its paradigms and how much they are used to code with c/c++.

How course it's hard for them right now.

Guess what, it was harder when they started c/c++ decades ago. There was less tooling, best practices were even less clear, all code bases looked different and the language ergonomics were way worse than today.

Give it some time. Some time for the language to mature of course. But more than that, some time for the dev to actually reach fluency, not only it the language and ecosystem, but on the general philosophy of this way of producing software. It's even harder given many have to unlearn years of experience and patterns that made them productive, and adopt, discover, or even even new ones to replace them.

We have hugely high expectations towards rust because of the amazing work the core team has already made in so little time.

I see the same reaction toward the last 2 flight crashes. People are shocked this can happen. I'm just amazed it doesn't happen more often. The institutions have generally done a fantastic job.

Now to say we should not fix what's broken in both cases.

But let's be fair to the incredible result we already got.

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

#96

Post by viraptor »

tsimionescu wrote: post #60
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…

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

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

https://github.com/thepowersgang/mrustc kind of does that. It assumes the input code is valid at the moment.

But if you want to experiment first, you have other language pairs you could use. Python + typed Cython, or Ruby + Crystal, or other options...

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

#97

Post by Jach »

flukus wrote: post #33
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 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. I think this is more post-hoc justification than anything else. There seem to be an awful lot of developers concerned about memory safety since rust started becoming trendy and I don't think many of them were coding in ada before rust e…

Rust's contribution is memory safety without a GC, so as a new approach it's somewhat exciting. But for most programmers before Rust and today, memory safety has been a solved problem not worth thinking about because most programmers use a GC language.

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

#98

Post by clanrebornx »

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…

People are downvoting not because Rust is better choice for this project with the cons you mentioned but because Go is far better choice if you want less mental overhead and total cost

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

#99

Post by 0815test »

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

> In Rust it's the overt explicitness of the borrow checker, and the friction it adds to one's programming.

Most, and perhaps all of the "friction" that the borrow checker adds to exploratory programming can be fixed with comparative ease by adding a few well-placed `.clone()` calls (for immutable data) and/or changing some type declarations to `Rc>` - at a minor cost to performance, in both cases. One might think that Rust needs to do more to support this use case, but given the performance implications, this is one example of how explicit can be far better than implicit. Regardless, it's absolutely the case that you can write "ALGOL" in Rust, just as you can write FORTRAN in any language. The code might not be at peak performance, it might even leak memory in rare cases, but it will do what you expect it to do otherwise.

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

#100

Post by viraptor »

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…

> the friction is coming from the fact that Rust can't be changed any more

The basic language as such doesn't change much, but what the compiler infers and accepts gets extended with almost every release. rustc from 2 years ago is a lot more strict than rustc now. And lots of lifetime annotations you had to do before, you can omit today.

The experience is much nicer and the friction definitely goes down.

Post reply on HN