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

231–240 of 283 posts

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

#231

Post by sjcoles »

JabavuAdams wrote: post #165

This is why I gave up on Haskell. Code is still (currently) written by humans. Sure the code was more terse, but I had to expend more time thinking about every tiny piece of that terse code. I've been programming for 36 years. Just as some people think out loud, I think by shaping and reshaping code. Top-down doesn't work for me, although I know there are other developers for whom it does. I like to build bottom-up b…

Even with a top down approach you can end up with insane type level machinations or group/category theory that only the best Haskell developer can decode. Sure it's elegant, but damn near indecipherable.

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

#232

Post by kazinator »

nicoburns wrote: post #118
coldtea wrote: post #106

Earlier quoted context omitted.

I do qualify that I speak about languages that are still "Algol-derived". Rust is not some significant paradigm shift (like e.g. Scheme vs C vs Prolog vs Haskell, etc). It's the same concepts and programming styles as C, C++ etc, plus fighting the borrow checker.

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.

You can easily implement borrowing in C++ classes.

I worked on a large C++ code base (some 15 years ago, before Rust existed) which did this kind of thing: it had references enforcing single ownership that was handed on assignment or passing.

Borrowing was of course done in the usual way, by passing down references (most often const ones).

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

#233

Post by olau »

tome wrote: post #206
mlthoughts2018 wrote: post #192

Earlier quoted context omitted.

It was first for a bank, later for a data analytics start-up, and then also for an education technology company. I had many skilled functional programmers on my team too, including a few people who had done work on GHC itself. I’ve also see code messes in many languages. It’s a business culture problem, has nothing to do with the language or paradigm. I’ll greatly dispute with about Python though. It has been a langu…

Very interesting. I suspect we may even have worked for the same bank! I'd love to discover how we came to such opposing conclusions. To give you a Python example, it encourages stuff like: def send_email(recipients, contents): if type(recipients) == str: send_one_email(recipients, contents) else: for recipient in recipients: send_one_email(recipient, contents) That is a flavour of convenience that people commonly im…

This isn't really spaghetti code, though, it's a syntactic sugar optimization gone wrong due to the Python 2 str/unicode split.

It's in the same league as people overloading operators in C++ to do silly things.

While some people like to harp on that, I don't think those instances are prevalent enough to actually cause that many bugs. YMMV.

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

#234

Post by tsimionescu »

larzang wrote: post #105
tsimionescu wrote: post #60

Earlier quoted context omitted.

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

I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably creep in when you're trying to architect and evaluate and code all at the same time. The kinds of things that make you smack yourself in the face for an hour wasted by the most trivial mistakes. In addition to my own personal experience this has been incredibly…

I don't have a problem with strong types, I agree with you. Dynamic types are usually too much hassle even for prototypes. I was talking more about stuff like Rust's borrow checker or dependent type systems.

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

#235

Post by [deleted] »

0815test wrote: post #99
coldtea wrote: post #79

Earlier quoted context omitted.

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

[deleted]

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

#236

Post by tsimionescu »

pdkl95 wrote: post #123
tsimionescu wrote: post #60

Earlier quoted context omitted.

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

> you just want to run it and see whether it at least sometimes produces the right output Then use a dynamic language like ruby or python and enjoy not only data type freedom, but also features like easy introspection and code manipulation at runtime. Protyping and experimentation in a REPL is much faster, easier, and memory safe . If you are just experimenting, why are you wasting time and effort on e.g. C++'s compl…

I never said anything about a release - I'm not even thinking about code you would commit. I'm talking about the kind of coding where you're exploring a new feature on your own machine - essentially doodling in an IDE instead of on paper. It makes no sense to me to make such code 'correct' - I don't even know if its useful to any extent, why would I care about its correctness?

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

#237

Post by kazinator »

nicoburns wrote: post #121
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…

C/C++ developers can't use Rust without learning new concepts . That's not a failure. If there were no new concepts, then there wouldn't be any point in the langauge in the first place.

> If there were no new concepts, then there wouldn't be any point in the langauge in the first place.

Not so; the same concepts can be clarified and captured in a better set of requirements, leading to better implementations of the concepts.

There can be a point in fewer concepts that are simpler.

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

#238

Post by shepmaster »

mrfredward wrote: post #157
shepmaster wrote: post #147

Earlier quoted context omitted.

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

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 this in C for years, but Rust rejects it.

- ...time passes...

- Oh, I understand why Rust rejects this code now.

- OH MY GOD I'VE BEEN WRITING CODE LIKE THIS IN C FOR YEARS

A conceptual borrow checker is something that every C and C++ programmer should be running in their head for every line of code that involves references / pointers that they touch. I'm happy to let the automated algorithm provided by Rust do that for me instead.

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

#239

Post by shepmaster »

duneroadrunner wrote: post #199
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…

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 scenario where it is demonstrated that the optimizers are good enough

This sounds like the sufficiently smart compiler (http://wiki.c2.com/?SufficientlySmartCompiler) argument. While I'd love to live in this world, we aren't there yet.

Even in such a world, there would still be reasons to choose Rust over C, such as standardized dependency management or a rich type system.

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

#240

Post by pjmlp »

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…

I complain about C's safety all the time, but it isn't as if Dennis and others weren't aware of its shortcomings in that regard.

> Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

-- https://www.bell-labs.com/usr/dmr/www/chist.html

C static analysis tools, being ignored since 1979, because "nobody has got time for that."

Post reply on HN