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

241–250 of 283 posts

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

#241

Post by pjmlp »

oscargrouch wrote: post #229
mcguire wrote: post #145

" 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., be…

As someone who was following Rust since its inception, i got pretty fond of the first Graydon Hoare's vision to it. It looked a lot like Swift is now, but with a different syntax and more FP dialects. As a im a (mostly) C++ programmer, despite the fact that i liked the language, i feel that the balance between what the language was giving me, and the productivity, was not worth it when compared to C++. I feel much mo…

I have a similar approach, just different languages.

Java and .NET platforms, with C++ only when really required.

So for me, and the people I work with, whatever alternative comes to replace C++, needs to fit into the same workflow and IDE mixed language development tooling that others are already comfortable using.

And I do advocate both ways, managed languages getting features that reduce the need to reach for C++, safer C++ replacements that might eventually succeed long term (C++ took 25 years to reach where it is now), and exactly because C++, or even C, isn't going away tomorrow, ways to improve existing code quality.

Because the ultimate goal is to improve our IT stack, and not celebrate yet another Morris Worm birthday.

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

#242

Post by pjmlp »

epage wrote: post #162
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…

> 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 I see these comments and it feels so foreign to my experience. The borrow checker was second nature to me because of my C++ experience. These were things I already had to juggle mentally. On rare occasions, it complained about something that I could prove was valid but I…

Were you trying to write GUI code?

Because of my experience it was also plain sailing, while doing the tutorials and exercises from the books I bought.

Then I tried to make a GUI application in Gtk-rs and had lots of fun with event handler callbacks, which are the main reason why Relm was created.

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

#243

Post by pjmlp »

adev_ wrote: post #193
fulafel wrote: post #58

Earlier quoted context omitted.

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.

> And you would probably want to focus on parallelism, where C++ again is not the best. Here again, this is wrong. 99% of highly scalable parallel code that run on supercomputers is C++ or Fortran. And there is reasons to that, if you want parallelism, you want generally performance. If you want performance you want control on NUMA, SIMD, cache locality, etc... and C++ gives you that. Not Java.

Yet Julia and Chapel are winning hearts of HPC researchers.

Java is not the only language with GC, there are others which offer control over NUMA, SIMD, cache locality, like .NET Native with C# 7/8, or D as two possible examples.

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

#244

Post by otabdeveloper2 »

sanxiyn wrote: post #26
adamnemecek wrote: post #24

Earlier quoted context omitted.

Most of those langauges don’t have the perf of rust or cpp.

Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.

> Java is usually within factor of two

No. That's on synthetic benchmarks. Run a real server and you see that Java shits its pants while a C++ service is running rings around it.

That's because memory/cache fragmentation and usage is vastly more important in 2019 than CPU cycles.

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

#245

Post by gmueckl »

pjmlp wrote: post #243
adev_ wrote: post #193

Earlier quoted context omitted.

> And you would probably want to focus on parallelism, where C++ again is not the best. Here again, this is wrong. 99% of highly scalable parallel code that run on supercomputers is C++ or Fortran. And there is reasons to that, if you want parallelism, you want generally performance. If you want performance you want control on NUMA, SIMD, cache locality, etc... and C++ gives you that. Not Java.

Yet Julia and Chapel are winning hearts of HPC researchers. Java is not the only language with GC, there are others which offer control over NUMA, SIMD, cache locality, like .NET Native with C# 7/8, or D as two possible examples.

But the GC is frowned upon a lot in the D community. A lot of D programmers try to make everything they write @nogc.

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

#246

Post by duneroadrunner »

shepmaster wrote: post #239
duneroadrunner wrote: post #199

Earlier quoted context omitted.

Yes, It's hard to deny the intuitive appeal, but what's notably missing from that blog post, and seemingly any other article about it, is a consideration of the cost/downsides of universal imposition of the "exclusivity of mutable references" restriction. Rust provides the RefCell wrapper to essentially circumvent the restriction on demand, but i) that also essentially circumvents the "invariant protection" benefits…

> Rust provides the RefCell wrapper There is also `Cell` ( https://doc.rust-lang.org/std/cell/struct.Cell.html ), which offers a different set of tradeoffs. > which policy do you want to be the zero-overhead default The one where: - The compiler can make more optimizations - I'm less likely to shoot myself in the foot my conflicting mutations is a good default for me, so I'm in favor of Rust. > a hypothetical future…

Oh yeah, there are plenty of reasons to prefer Rust over C++. I think it's also reasonable to favor Rust's "exclusivity of mutable references" default as a matter of personal preference. I'm just not sure the formal or technical argument has yet been made that universally applying that restriction is necessarily the "better" default overall.

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

#247

Post by fooker »

Yeah, Rust seems to have an ergonomics problem and the only response we are seeing is "you're holding it wrong".

I would rather work on interesting projects than use interesting tools for not-so-interesting projects. So far, for things I am interested in, C++ seems to be the tool of choice.

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

#248

Post by skohan »

oscargrouch wrote: post #229
mcguire wrote: post #145

" 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., be…

As someone who was following Rust since its inception, i got pretty fond of the first Graydon Hoare's vision to it. It looked a lot like Swift is now, but with a different syntax and more FP dialects. As a im a (mostly) C++ programmer, despite the fact that i liked the language, i feel that the balance between what the language was giving me, and the productivity, was not worth it when compared to C++. I feel much mo…

I have taken a similar approach, although I tend to rely more on C than C++. I think Swift has somewhat similar advantages to Rust in terms of safety, but accomplishes it while being a largely permissive language rather than by putting the developer in a safety "jail" where it's almost impossible to make a mistake.

I know this comes at the cost of performance when compared to Rust when compared to memory management, but the value proposition in terms of productivity is huge. And recently I've done some experimentation with optimizing Swift for performance, and Swift can actually do surprisingly well there too if you stick to certain patters.

I think Rust has its place, and for things like kernel development, firmware, or software for a mars rover where you absolutely want the strongest compile-time checking of your code with respect to safety with a minimal cost to performance, it is a natural choice. I'm not convinced it's categorically better for all use-cases.

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

#249

Post by dan-robertson »

pcwalton wrote: post #223
blub wrote: post #83

Earlier quoted context omitted.

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 so that it becomes as ergonomic as other languages people are used to. What is your proposal, specifically? It's not that we weren't listening to C++ programmers 10 years ago. We put a ton of effort into making Rust as easy to use as possible. Rather, it's that the problem of memory safety without GC is fundamentally hard. If I could wave a ma…

Do you think it was obvious that such mutability rules and borrow checks were sufficient before languages like rust were invented?

What about a more impractical approach like e.g. ATS?

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

#250

Post by [deleted] »

dvnguyen wrote: post #160

My hypothesis is a software growth, like a business or an economy, is fueled by debt. We create technical debts, both deliberately and accidentally, to write software faster. And when the software proves itself as a viable project, we could (ideally) start paying the debt. Rust forces users pay certain kinds of debt upfront that makes Rust attractive for rewriting, but I don't think it's that much attractive for gree…

[deleted]
Post reply on HN