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

261–270 of 283 posts

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

#261

Post by steveklabnik »

fooker wrote: post #259
steveklabnik wrote: post #255

Earlier quoted context omitted.

> the only response we are seeing is "you're holding it wrong". We had such a huge push last year for ergonomics that there's a segment of the community that's still upset about it. We're very interested in improving them; if you have good ideas about it, you'll get heard out.

Can you point me to a document listing the changes from this effort?

Probably the closest is https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html, which laid out the plans to do so. That being said, there wasn’t a single real document I can point you to: it was a label attached to a number of RFCs, and not really tracked as one thing. Some stuff that ended up landing under this banner was:

Non-lexical lifetimes

“Match ergonomics”

Implied lifetime bounds

The anonymous lifetime

The question mark operator

Async/await (this one is still in progress)

The removal of “extern crate”

... and some other things I’m sure I’ve forgotten. I also said “last year” but that blog post is from 2017, and that’s because it took a long time for RFCs to be created, accepted, implemented, and stabilized; a lot of this stuff landed in the latter half of last year, though some before then too.

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

#262

Post by IshKebab »

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.

This is so misleading. Sure you still have to think about borrowing in C++ but in C++ you only have to convince yourself that you got it right. You don't have to convince a dumb child that barely understands variable scopes.

The benefit is of course that the dumb child is 100% reliable so if you can convince him then you are 100% sure you got it right...

But please can we stop pretending that it isn't a massive pain in the arse to convince the borrow checker that your code is ok.

Also as someone else pointed out, if you are only writing single threaded code the mutable borrowing rules are needlessly restrictive.

I like Rust but it really irks me when people pretend it is as easy as C++. It isn't. It is much harder - it's just that when you're done you have (probably) a better result.

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

#263

Post by littlestymaar »

tombert wrote: post #256
pcwalton wrote: post #223

Earlier quoted context omitted.

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

Speaking out of genuine ignorance here...if the only ways to get memory safety without GC, how does Swift or Objective C do it with ARC?

Arc is a kind of automatic memory management that's included when people talk about GC in general.

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

#264

Post by pcwalton »

tombert wrote: post #256
pcwalton wrote: post #223

Earlier quoted context omitted.

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

Speaking out of genuine ignorance here...if the only ways to get memory safety without GC, how does Swift or Objective C do it with ARC?

Reference counting is a form of garbage collection.

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

#265

Post by tombert »

pcwalton wrote: post #264
tombert wrote: post #256

Earlier quoted context omitted.

Speaking out of genuine ignorance here...if the only ways to get memory safety without GC, how does Swift or Objective C do it with ARC?

Reference counting is a form of garbage collection.

Yes but this is done at compile-time, not runtime, isn't it?

EDIT: Upon reading some stuff, apparently I am mistaken, and it's got runtime overhead. Silly me.

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

#266

Post by Const-me »

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…

Same here, only C# instead of Swift. Native interop through C API adds some friction, but despite that, I also find it easier to use two distinct languages.

C++ excels at interop. As you mentioned there’re many libraries that only support of C or C++ but for me their set is different, most often I need to consume native OS APIs and GPU APIs. Also, C++ is good at number crunching, when performance matters, e.g. because first party SIMD intrinsics support.

For everything else I use C#.

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

#267

Post by anfilt »

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…

Unabashedly, I think leaving in it pure C would have been better. Well, if that was of their main reasons. Although, it sounds like they wanted more "infrastructure".

There is a lot of C infrastructure, almost anything can work with C too...

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

#268

Post by steveklabnik »

tombert wrote: post #265
pcwalton wrote: post #264

Earlier quoted context omitted.

Reference counting is a form of garbage collection.

Yes but this is done at compile-time, not runtime, isn't it? EDIT: Upon reading some stuff, apparently I am mistaken, and it's got runtime overhead. Silly me.

You're not totally wrong; that's the "A" in ARC: Automatic. It automatically inserts code at compile time, but that code has a runtime effect.

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

#269

Post by yoklov »

shepmaster wrote: post #238
mrfredward wrote: post #157

Earlier quoted context omitted.

I like the blog post, and I mostly agree with you that shared mutability can cause problems in big programs. It's something I try to keep to a minimum in most code I write, and I'm better at avoiding it after learning rust. The thing is, getting rid of shared mutable state entirely is a huge paradigm shift. It means many libraries (GUI libs especially) can't be cleanly wrapped. It means throwing away common data stru…

> It means throwing away common data structures like linked-lists It does not require such; the Rust standard library even has a LinkedList ( https://doc.rust-lang.org/std/collections/struct.LinkedList.... ). > A C++ programmer [...] may take years to get comfortable with the borrow checker. One of my earliest / biggest revelations when learning Rust went something like: - Rust is stupid; I've been writing code like…

Often when people [0] discuss the difficulty of writing linked lists in Rust compared to C++, they mean intrusive linked lists.

These are still very difficult in Rust. I've heard pinning being stabilized makes them possible safely, but I haven't looked further.

[0]: At least, when I was starting Rust, this is what I would mean when I complained about linked lists.

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

#270

Post by yoklov »

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…

IIUC, for typical programs, most of Rust compilation time is spent waiting for LLVM to spit out results.

There's a plan to use https://github.com/CraneStation/cranelift for debug builds instead of LLVM, which would make them faster at the cost of supporting fewer targets, and producing worse code.

Post reply on HN