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

181–190 of 283 posts

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

#181

Post by distances »

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…

One-sided changes to build configuration sounds like an issue with code reviews though. It shouldn't be possible to merge something like that without others agreeing.

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

#182

Post by bluejekyll »

ThrowawayR2 wrote: post #168
__s wrote: post #113

/r/rust thread: https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_... You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community..

> You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community. Having read those comments, many of them can be best characterized as politely dismissive, e.g. from the top rated comment " If the author is more comfortable writing this code in C++ it makes sense to use it, but I feel like there is a long way to go to make…

How would you describe the trade-off between safety and the developer productivity listed as the reason in the article?

The comment seems to just be saying that it’s reasonable for someone to make this trade off when they are more knowledgeable and familiar with one language rather than another.

I think your reading quite a bit into that comment to take it as elitist.

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

#183

Post by kbenson »

lixtra wrote: post #161
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…

Depending on the situation a write unsafe fast fix later maybe the more economic approach. Especially if the code is more exploratory, changes a lot and large parts will be finally discarded.

It seems to me that letting yourself work under the assumption something may be easy to fix later when you add the safety constraints back is just asking for major pains when it isn't easy. A wrong assumption at that level can render your entire algorithm unworkable if your plan was to make it safe in the end, since some patters just don't lend themselves to easy expression in rust. Then you're stuck with the choice, leave it unsafe and worry about it from them on, or rewrite it safely using an altered or entirely different algorithm. That doesn't seem like a gamble that's worth it to me.

Even for exploratory code. Unless it's such a performance critical portion of the project that I'm willing to write it in a different language for speed, why bait myself so?

If one of my goals for a project is to write somewhat functionally, I wouldn't start off with an exploratory approach using procedural techniques. I think we can all see what I'd probably end up with in the end, and it might work, but it probably wouldn't have some of the attributes I was hoping for.

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

#184

Post by ilovecaching »

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…

Personally, I had the same experience as you did, except the borrow checker also helped me unlearn a few bad habits and gave me a deeper understanding of references. Now it is second nature, and I rarely every fight the borrow checker. I think part of it is planning ahead.

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

#185

Post by mlthoughts2018 »

loup-vaillant wrote: post #110
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…

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

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 errors, indecipherable crashes, etc. no matter what degree of strict verification tooling you use. The introduction of lazy evaluation, difficult to debug tail recursion implications on memory consumption, elevating IO into the type system, burying details deep in type class patterns, relying on dozens of special case compiler directives to enhance Haskell... it becomes the same shit code mess as any other paradigm.

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

#186

Post by jayd16 »

gmueckl wrote: post #64
jayd16 wrote: post #56

Earlier quoted context omitted.

Mono runs fine. IL2CPP is more of a work around to get AOT on iOS and Burst is just a nice linter but you could write the same tight loops now and mostly likely get very close. Plus, Burst isn't even out so its odd to bring it up as necessary.

Unity makes it very clear in their blog posts that Burst is a special vectorizing compiler. It is not a linter at all. I am not sure where you got that notion. IL2CPP was required to be able to stick with C# and stay relevant for mobile gaming. They forced themselves into this corner by wanting to stay with C# and become relevant for mobile gaming. Compare all this to Unreal. By sticking to C++, they do not have to c…

Burst is basically an upgrade to Roslyn with some perf warnings set to errors.

IL2CPP is literally required on iOS but the perf gain you get on Android was never very good. Because of its general instability, a lot of games just ship in mono mode.

It's funny that you're saying both Burst and IL2CPP are required. Can't you see that Burst is an admission that IL2CPP wasn't the way to go?

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

#187

Post by bluejekyll »

mlthoughts2018 wrote: post #180
ThrowawayR2 wrote: post #168

Earlier quoted context omitted.

> You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community. Having read those comments, many of them can be best characterized as politely dismissive, e.g. from the top rated comment " If the author is more comfortable writing this code in C++ it makes sense to use it, but I feel like there is a long way to go to make…

Exactly. A bunch of link spam to reddit or quora doesn’t add up to evidence that the Rust community is reasonable or fair in its evaluation of alternative language choices or trade-offs against other languages.

Are you suggesting that Rust is not as safe as it claims? Or that C++ is as safe as Rust?

There’s a lot of research to disagree with either of those positions.

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

#188

Post by tome »

mlthoughts2018 wrote: post #185
loup-vaillant wrote: post #110

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…

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…

Interesting. I would be interested to know more details about what you worked on and with whom. This hasn't been my experience in any of the four jobs I've used Haskell at.

I don't deny that Haskell leads to spaghetti code messes, unexpected runtime errors, and indecipherable crashes, but the Java that I've previously worked with and the Python I currently work with suffer from those to a degree greater by an order of magnitude.

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

#189

Post by slavik81 »

loup-vaillant wrote: post #126
blattimwind wrote: post #120

Earlier quoted context omitted.

> you are making a mistake that in C++ would have bitten you down the line. Taking some C++ code from an explorative phase that "usually works kinda ok" to something seaworthy requires, in my experience, a huge amount of work (which usually neglects a few issues that will bite you later regardless). I'm not so sure the (probably) faster exploration in C++ compensates for this compared to more "strict" languages like…

I found that strict compile time checks speed up my exploratory phase. That's because the type system provide an even tighter feedback loop than a REPL, and effectively cuts down the search space. Other people seem to have experienced the opposite, though. I have no idea why.

To me, the question is whether the time spent dealing with compiler errors is due to fixing real problems that the compiler is pointing out, or whether that work is mostly reworking a correct program to satisfy the compiler when it cannot yet see that the program is correct.

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

#190

Post by mlthoughts2018 »

bluejekyll wrote: post #187
mlthoughts2018 wrote: post #180

Earlier quoted context omitted.

Exactly. A bunch of link spam to reddit or quora doesn’t add up to evidence that the Rust community is reasonable or fair in its evaluation of alternative language choices or trade-offs against other languages.

Are you suggesting that Rust is not as safe as it claims? Or that C++ is as safe as Rust? There’s a lot of research to disagree with either of those positions.

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 interpreted as well, and only choose small sections of code to target for a specialized compiled implementation.

In those cases, avoiding the overhead of a compiler and using rapid unit tests with high coverage as an alternative to compiler checks may often be a far safer and superior way to develop code, leading to adequately safe and performant code that is easier to maintain, faster to create, easier to explain, etc.

All I’m saying is that Rust is another tool in the toolbox. It’s not intrinsically or unilaterally better than any other tool, and other tools can inhabit parts of trade-off space that make them better choices than Rust, even for applications that need memory safety or high performance.

In my experience though, most interactions with Rust community leave me feeling like a vocal and significant fraction are trying to seriously claim that Rust is categorically and unilaterally a better choice across almost all possible use cases, let alone across a wide range of practical use cases.

Post reply on HN