Live data from Hacker News

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

blogs.dust3d.org

221–230 of 283 posts

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

#221
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 think the assumption that static typing means things take more time requires justification. Usually I see the assertion given from people who naturally take longer getting things to pass compilation just because they're not used to using it. When I use dynamically typed languages I find footguns in undefineds and empty strings where others wouldn't. I also have to write tests - which themselves may have bugs - for things that static analysis could do on its own. Why use expensive dev time for this instead of cheap CPU time?

>Underlying that model seems to be a concept of software like a sort of renaissance master's marble statue, error free and perfect at time of production.

Most of the time I'm writing code isn't for the first implementation of a green-field feature and, really, most programming problems aren't that hard in terms of logic flow. If I refactor and the type system and static checking don't complain, I can be reasonably sure it's going to work. And I've seen too many 'temporary hacks' that became forgotten and leaked to review or production.

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

#222

Earlier quoted context omitted.

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

It's hard to implement unsafe patterns in safe language. It's hard like using ASM with Java, because Java is platform independent language, while ASM is platform dependent language. This impedance mismatch causes problems, which can solved by wrappers. If we are talking about emulator, why not just make clear communication between CPU, RAM, and graphic device? Memory can be split into rows (e.g. by split_at()), so gr…

I can't understand how using split_at() would work...if the CPU and the GPU both have a reference to the RAM, we're still using an Rc>. If the slice gets passed into the CPU and GPU's run() functions, then how does this magical memory manager know what to pass ahead of time?

>It's hard to implement unsafe patterns in safe language.

I agree with this 100%. And I think that for certain problem domains, rust provides more safety than you actually want.

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

#223
post #83

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 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 magic wand and release an incompatible Rust 2.0 with memory safety and no new concepts to learn over C++, I'd do it. But it's easy to just say you want a new language. It's a lot harder to actually design such a thing.

I generally think that if you want memory safety, you must either have a garbage collector or the mutability rules and borrow check. There is no other option.

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

#224

Earlier quoted context omitted.

I worked professionally in Haskell for a long time and I cannot disagree with you more. This is always the promise of strict functional languages but in a business setting where the very nature of what you build has to be arbitrarily mutable at the whim of competing interests between stakeholders, engineers, customers, etc., it just doesn’t work. You end up with the same spaghetti code messes, unexpected runtime erro…

> in a business setting where the very nature of what you build has to be arbitrarily mutable— I just don't use Haskell there. I personally use OCaml for my data in, data out problems (compilers, generators…), but for inherently interactive and mutable stuff I just do imperative programming. Of course the type system (and the performance characteristics of the runtime!) must be suited to the problem domain. > burying…

> “Looks like someone went overboard.”

All these things are basically bare minimum table stakes to do anything in the language at all, particularly enabling dozens of compiler directives for language feature extensions. That is Haskell 101 practically, which is actually one of the hugest problems with the language.

Saying this is “overboard” in Haskell is out of touch with the practical realities of using the language.

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

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

> 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. You've picked a very poor example to repeat that tired old addage. You're using an example of someone who admits struggling with memory management issues who has just started learning a programming language which he doesn't master, and after he grew t…

> in a language which doesn't warn him about how broke his code is.

Can you make a citation from the codebase to back up this claim?

The classes in the various widget.h headers have members that are plain pointers; that might be one place to start looking.

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

#226
post #219

Earlier quoted context omitted.

No, not at all. Rust is a very good tool and is useful in many situations. I believe it offers better automatic memory safety. However, there are many cases when Rust is not a good tool for the job, and when specifically having greater manual control of memory or thread safety is a better choice. Additionally, in many applications you can build almost everything in a fully dynamically typed language, often interprete…

A vocal and significant fraction of any community of reasonable size is going to be populated by blowhards.

I think it's still fair to say that the Rust community either attracts, or doesn't discourage this type of advocate in a way that other communities don't. Personally I've encountered this type of behavior in a few situations:

1. When Swift for TensorFlow was announced, the team released a document explaining that they had narrowed the language choice to 4 languages including Rust, and eliminated Rust based on the sharp learning curve. Once commenter unrelated to the project logged an issue on the GitHub page and went on for many multi-paragraph quotes about how Rust should have been the choice.

2. In a thread about gfx-portability, which similar to MoltenVK brings the Vulkan API to Apple platfortms, when the original poster was questioned about the comparative completeness and and performance of these two implementations, they were completely unable to offer details (like come on, you can't even say what percentage of the tests are passing based on the Vulkan portability standards? You never benchmarked against the most similar product on the market?) and deflected to making totally unfounded claims about how MoltenVK is unsafe and even dangerous to use.

3. In a thread about Rust syntax, I made a comment about how I personally lamented some of the choices made in the language, like going with snake_case as a convention, and naming dynamic arrays Vector. I was promptly downvoted and received several fervent responses explaining why my personal taste was objectively wrong.

I think Rust is an interesting and promising language, but there does seem to be a somewhat tribal tendency in the community which is a turn-off for me.

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

#227
post #37

Earlier quoted context omitted.

Maybe, but hot reloading is very very useful. It is mostly a development time only feature anyway.

I believe we have seen Casey Muratory doing hot code reloading in C++, in his Handmade Hero stream. Compile the dll, reload & test the dll, without exiting the game runtime he's developing. The Yi editor, written in Haskel, I believe does hot code reloading as well. The XMonad window manager can be recompiled and reload while keeping your windows up (the configuration file is actually Haskell code). --- Yes, hot code…

It's only incompatible with Link Time Optimization and changes to static dispatch or structure, but anything that could have exposed as a COM object could be used.

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

#228

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. Dunno about Rust specifically, but I have written a little Haskell, and a significant amount of OCaml. I found that the type system reduces my cognitive overhead, compared to looser languages like Python or Lua. The compiler is disciplined…

Couldn't agree more. It was why my transition from Javascript (Node) to Go was very freeing - I had been so used to being constantly paranoid about my data types from Python and Javascript that even the most modest types of Go made a huge relief. Likewise, with Rust it is a relief after Go. In Go interfaces are a massive part of the language and they can only be pointers, which means much of your programming experien…

I can definitely see where the author was coming from in terms of new code. I've been of the opinion that it's probably better to greenfield new systems alongside a GC'd runtime(which makes Go a pretty good fit, but also D, Nim, etc. - and for the very experimental stages where the type layout is minimally understood - Python, Lua, JS, etc.), and to take on external dependencies to get a result working - and then rewrite parts with manual memory and custom libraries where the spec needs tightening.

The main downside to this is that you're rewriting stuff, but the goal of the rewrite should be to express what is essentially the same functionality in more detail.

Where I think the author might have erred is in switching between three different manual memory languages in the hopes of faster development. The algorithms needed for a 3D tool have a pretty high base complexity, making it hard to bootstrap the codebase - and I suspect that C++ will ultimately frustrate him just as much as Rust and C did before.

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

#229

" 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 more productive in C++, the language is still faster, with a low memory footprint in the majority of cases, and with modern C++, smart pointers, move, a correct understanding of the ownership model .. the bad sides of it, the ones Rust did a better job shelving us from, from my point of view are not worth paying for the lack of productivity i felt in Rust as compared to C++.

I know this is an unpopular opinion here in HN, but I decided to take a different approach .. instead of "one language to rule them all" i tend to use C++ for what's good at, and Swift for more application centered goals , because its nicer than C++ and Rust (in my opinion), release you from the burden of managing memory all around while being very fast at the same time.

Swift for me is "the better Java" we were looking for, Rust does not seem appealing in this arena (and the same goes for C++ here), while you pay for what you use in Rust in terms of productivity, even compared to C++.

The other thing that makes C++ a better option in my opinion, is the ammount of libraries and codebase you have access to, not only in C++, but in C. Very important codebases are either C or C++, even the newer ones like Tensorflow or V8, Chrome, LLVM, etc ...

I understand the importance of what Rust provides, I like its goal, but your comment sounded like the OP was either stupid or lazy / incompetent by using your anedoctical evidence. (While in the same anedoctical example you are the hidden figure who are sensitive about security while still using C++, as the 'lazy guy', enabling -Wall, using Valgrind, etc)

When I entered in the comments section here, I was just expecting the sort of comments in the spirit of "how could you even do that?"

PS: Im not the kind of guy who tends to disable -Wall -Werror to have more productivity and i would not favor C ++ in exchange for Rust, if i feel the balance were better among what i pay in terms of productivity were fair in exchange for more safety as compared to what I have now with C++.

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

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

> 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. Dunno about Rust specifically, but I have written a little Haskell, and a significant amount of OCaml. I found that the type system reduces my cognitive overhead, compared to looser languages like Python or Lua. The compiler is disciplined…

Ah, but in this case you have already done the spec, otherwise the type system couldn't have checked it.

With a more loose way of going about things, you don't have to write the spec. Spec'ing is hard, sometimes harder than actually solving the problem.

I feel like someone is going to point out that spec'ing is a lifesaver in a certain situation, and I would agree. But perhaps not all situations.

Post reply on HN