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

121–130 of 283 posts

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

#121

Post by nicoburns »

blub wrote: post #83
geezerjay wrote: post #34

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…

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.

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

#122

Post by blattimwind »

sanxiyn wrote: post #37
adamnemecek wrote: post #32

Earlier quoted context omitted.

Hot reloading doesn’t provide safety guarantees.

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

Unloading/reloading modules is perfectly possible, though in my perception relatively less common on Unix/Linux, while slightly more common in Windows land (e.g. DLL plugins, resource/translation containers etc.)

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

#123

Post by pdkl95 »

tsimionescu wrote: post #60
geezerjay wrote: post #34

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…

> 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 complex type system? If you don't care about memory leaks, why waste any effort on memory management when the garbage collector can handle that for you?

> starting from Rust but setting a flag to turn borrow checker errors into warnings

Experience suggests the "we'll do it right in the next version" argument leads to "prototypes" being shipped as the "next" (only) version.

The difficulties imposed by Rust is the goal. Actually writing correct and safe code is inherently a difficult problem. Rust is trying to force programmers into actually addressing that problem. Writing similarly correct and safe C++ is also time consuming and difficult. The difference is C++ lets the programmer shift that work and expense onto the user in the form of time-wasting crashes and expensive security vulnerabilities.

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

#124

Post by Const-me »

unrealhoang wrote: post #109
guitarbill wrote: post #104

Earlier quoted context omitted.

> proving they're implemented correctly never is Let's be clear: Rust is still far away from formal verification; the borrow checker won't save you from logical errors. Second, data structures like graphs, trees, hashmaps are well understood and have a lot of algorithms built on top of them. Algorithms with a lot of research behind them, and complexity analysis. While complexity analysis doesn't always equal performa…

Your argument doesn’t make much sense. You can use unsafe and raw pointer to do EVERYTHING you can do in C/C++ and it will be just as safe as you write it in C/C+. And then, you can (ab)use the type system to make sure you or your team cannot use it in the wrong way.

> and it will be just as safe as you write it in C

C++ standard library containers have guarantees about iterators and pointers invalidation, e.g. std::list never invalidates any of these, unordered_map invalidates iterators when rehashed and never invalidates pointers to either keys or values. This allows building unsafe data structures on top of standard collections, and then compose custom unsafe data structures on top of each other.

This makes C++ both safer (at least from memory leaks) and easier to use compared to unsafe rust.

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

#125

Post by vbezhenar »

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…

That's true. Different projects require different quality. The projects I'm working on are tolerable to bugs. I just need to know that bug happened (from logs or user complaints) and I need to fix a bug in a timely manner. I don't need to produce bug-free code. I don't need to produce fastest possible code either, servers are seriously underutilized and there's a lot of CPU and memory. I'm using Java because that's what I know well. I like Rust idea, I'm tinkering with it because I'm kind of perfectionist and I like Rust approach, but I won't apply it to my current work in foreseeable future. Even switching to Kotlin from Java was a hard call, because so many people don't want to learn anything new and I can't really blame them.

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

#126

Post by loup-vaillant »

blattimwind wrote: post #120
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…

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

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

#127

Post by Const-me »

guitarbill wrote: post #116
unrealhoang wrote: post #109

Earlier quoted context omitted.

Your argument doesn’t make much sense. You can use unsafe and raw pointer to do EVERYTHING you can do in C/C++ and it will be just as safe as you write it in C/C+. And then, you can (ab)use the type system to make sure you or your team cannot use it in the wrong way.

why would i use rust in the first place if i was disabling the borrow checker? isn't that the main selling point? because of the ecosystem? because it's easier to hire rust programmers than C/C++ programmers, or get more open source contributions from rust vs C/C++? unlikely with a learning curve or community like that.

Rust only disables these checks very selectively.

The idea is good, MS did same in C# since the first version in 2002. Allows to do pointer arithmetic when you really need to, for performance or native interop.

What I don’t like about Rust is they use unsafe to workaround language limitations.

In C# I have only used unsafe code couple times over the course of 20 years. The standard library doesn’t use unsafe code either, at least in modern .NET all these collections are 100% safe code. The main, safe subset of the language is good enough for the majority of practical applications.

In Rust there’s tons of unsafe code in standard library, substantial amount of unsafe code in third-party libraries, and if your software is complex enough, your own code will likely contain usafe as well. This causes safety issues: https://medium.com/@shnatsel/how-rusts-standard-library-was-...

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

#128

Post by kiriakasis »

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…

Also I think that with enough .clone(), raw pointers and `unsafe` you can avoid almost all borrow checkers errors.

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

#129

Post by baq »

guitarbill wrote: post #104
baq wrote: post #89

Earlier quoted context omitted.

> Even without trees, consider a simple LRU cache structure. Trivial to implement in most languages by combining linked list with hash map. Rust implementation is more than 1000 lines of code, many of them are unsafe: ... in this context, criticizing using unsafe in rust and comparing that to C++ is comparing apples to oranges. GC languages aren't even worth mentioning here. > It’s not necessarily an improvement. Whe…

> proving they're implemented correctly never is Let's be clear: Rust is still far away from formal verification; the borrow checker won't save you from logical errors. Second, data structures like graphs, trees, hashmaps are well understood and have a lot of algorithms built on top of them. Algorithms with a lot of research behind them, and complexity analysis. While complexity analysis doesn't always equal performa…

> Let's be clear: Rust is still far away from formal verification; the borrow checker won't save you from logical errors.

completely agree.

> Second, data structures like graphs, trees, hashmaps are well understood and have a lot of algorithms built on top of them.

well understood, yes, by authors of textbooks and papers. your average programmer may have understood them once, before he made it to the enterprise and started passing buckets of bits between http endpoints for a living.

> Algorithms with a lot of research behind them, and complexity analysis. While complexity analysis doesn't always equal performance, if I can't use these universal tools in your language, I'll probably think of it as a toy language which stops me from getting stuff done, which is still what most of us are paid for.

you can write a recursive data structure in Rust in the same way you'd write one in C++ - use unsafe pointers, even the asterisk is the same. nothing is stopping anyone from doing that, in fact there are lots of examples on crates.io and in the stdlib.

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

#130

Post by p0nce »

gmueckl wrote: post #21
petre wrote: post #13

Earlier quoted context omitted.

This was my impression as well when I tried Rust - always fighting the compiler. None of this happens with D. You just code away and keep being productive without the annoyances of C++. In fact C++11 and 17 are less and less annoying.

Being able to use more D would be nice! But the binding issues remain the same there. There recently was talk about having the D compiler emit C++ headers for exports from D modules automatically. This would be an instant killer feature for me.

dpp is en effort that allows to include C++ headers, also there is ongoing effort to link with C++.

https://github.com/atilaneves/dpp

Post reply on HN