Why I rewrote the mesh generator of Dust3D from Rust to C++ • Hacker News Board

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

#281

Post by Thiez » Sun, Mar 17, 2019, 10:48 PM UTC

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…

Just define your memory as `Rc]>` (or something wider, depending on architecture) and you're fine, right?

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

#282

Post by kybernetikos » Mon, Mar 18, 2019, 10:21 AM UTC

mjburgess wrote: post #22

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…

Static checking burdens the developer with thinking more, etc. -- for sure. The cost is requiring a developer with stronger cognitive abstracting skills. Those people tend to be academics (its almost a definition of a good academic) and also, perhaps, less pragmatic. The ease of programming is not merely a matter of knowledge or experience, base cognitive skills play a very significant part which are largely an at-bi…

> Static checking burdens the developer with thinking more, etc. -- for sure.

I'm not sure I agree. Most type languages as implemented in common programming languages are bad at describing abstraction. This means that if you're programming in one of these languages, you are forced to reduce your level of abstraction (which is sometimes touted as an advantage).

And just because someone's smart enough to find working out how to satisfy the type checker an enjoyable challenge, doesn't mean they're dumb enough to think that just because it's fun it is always a good use of their time.

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

#283

Post by jamwt » Tue, Mar 19, 2019, 12:47 AM UTC

IshKebab wrote: post #262

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

> I like Rust but it really irks me when people pretend it is as easy as C++. It isn't. It is much harder

No it's not.

"hard" is not single dimensional.

"hard" to write your first hello world? No, both are easy.

"harder" to write your first moderately-sized program that basically works? Yes, for almost everyone. You'll fight the borrow checker. The learning curve is real.

"harder" to write your first large/medium, correct program? Definitely not. The safety will save you, here. It's not just memory. It's no nulls, it's no exceptions, pattern matching exhaustion enforcement, baton-passing session type patterns, race-freedom, and so on. The "it compiles, it works" dynamic is akin to OCaml/SML, if you've used those at all. Except it's even better because you get prompt resource finalization.

"harder" to write your nth program after ~6 months of usage? Not by a long shot. Rust is actually an incredibly expressive language. Once you learn to shape code the way the language expects, you'd be shocked at how productive you are. It's in the same ballpark as go, perhaps a little better if you're doing something nontrivial due to the power of generic libraries.

I spend almost no time "fighting" the borrow checker, as do most ramped-up Rust programmers. It's pretty much all win at this point. It's a different category of language than C(++). It actually gets a little exhausting hearing people talk about how hard the borrow checker when folks have barely used the language.

These days, the only time I'll use a GC is if I'm writing something _very_ fast and short in Python. An experiment, a prototype, or a tool. A short REPL session. I really do not miss GCs otherwise.

But yes, compile times are somewhat slow. If you go template crazy in C++, you'll be in the same ballpark. But the "equivalent" C codebase will smoke it.