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

111–120 of 283 posts

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

#111

Post by dahfizz »

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…

I have started to see a worrying trend were developers focus more on how easy it is to develop X rather than how good of a finished product is X.

It makes sense for developers to want development to be easier and for businesses to want it to be faster but it feels lazy and cheap to actively avoid tools that would help us produce better programs with much stronger guarantees in the name of ease of development.

It's not like rust's checks are arbitrary. If you wanted Rust's safety and guarantees in C++, then you would still have to do all the things the rust compiler is doing for you.

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

#112

Post by pjmlp »

mewse wrote: post #94
pjmlp wrote: post #71

Earlier quoted context omitted.

The same was said about the game developers using Pascal and C instead of Assembly, followed by game developers using C++ instead of C. The industry always needs some pioniers willing to do the investment regardless of the naysayers.

Note that the game industry avoided C++ for a long time because those early C++ compilers produced code which was very large and quite a lot slower than you'd get from C, so C++ was kind of a non-starter when you were writing code for the consoles of the day which had slow processors and only a few megabytes of RAM. You just couldn't afford the overheads of C++ or your competitors would eat your lunch. It wasn't abou…

The pioneers were the studios using Watcom C++ on MS-DOS, while others were still being dragged into Windows with plain old C, while complaining about losing hardware access until Wing was released.

And the studios that were forced to adopt C++ when the PlayStation SDK required it.

So nothing speaks against other languages getting over the same kind of acceptance issues.

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

#114

Post by 0815test »

arcticbull wrote: post #70
gcc_programmer wrote: post #46

I wonder how many of the Rust defenders in this article actually know C++ and have written a production used Rust system, instead of a side-project on github, so that they can compare in an informed way? The author certainly has, but who else has? Step forth priests of Rust! As for me: I use C++ at my job daily but have never done Rust so I cannot compare. What I do know about is "memory safety" in C++, and to be hon…

Rust memory management is just RAII, and there are no exceptions, just nice Result types and syntax that makes returning them and handling error cases simple and pleasant. If you want to handle closing a socket, it’s as easy as implementing the Drop trait on your type. Without an unsafe block there’s no way your destructor won’t be called. struct Socket(u16); impl Drop for Socket {...} To answer your question there’s…

> ...Without an unsafe block there’s no way your destructor won’t be called.

Unfortunately, this is not correct. Resource "leaks", involving failure to drop a resource which is no longer in use, are possible in Rust, and the borrow-checker won't protect against them. They're most likely very rare in idiomatic Rust (the case I know about has to do with RC-cycles) but they're possible.

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

#115

Post by loup-vaillant »

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.

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 reloading is bloody useful. It is also perfectly compatible with static typing. I see no good reason for statically typed languages to have worse support for it.

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

#116

Post by guitarbill »

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.

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.

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

#117

Post by ekidd »

gcc_programmer wrote: post #46

I wonder how many of the Rust defenders in this article actually know C++ and have written a production used Rust system, instead of a side-project on github, so that they can compare in an informed way? The author certainly has, but who else has? Step forth priests of Rust! As for me: I use C++ at my job daily but have never done Rust so I cannot compare. What I do know about is "memory safety" in C++, and to be hon…

> I wonder how many of the Rust defenders in this article actually know C++ and have written a production used Rust system, instead of a side-project on github, so that they can compare in an informed way? The author certainly has, but who else has?

Hello. :-) I started writing C++ around 1992, and was lead programmer on various C++ production systems from 2002 until 2011. I worked with valgrind, unit tests, and boost/std::tr1 C++, but not C++14 or 17.

For the past three years, I've been writing production systems in Rust. Here are some things I've observed:

- If your C++ code relies heavily on complicated webs of objects that all mutate each other (as found in many game and GUI designs), you'll have a bad time translating that code to Rust. If your C++ code tends to be more functional, idempotent, or transaction-based, and if it has clear ownership of objects, then translating to Rust will be much easier. For example, Rust seems to work better with ECS-based games and React-like GUIs.

- Rust is significantly weaker than C++ for designs which use integer template parameters (e.g., "vec") or partial template specialization.

- Modern C++ allows you get ownership 99% correct, if you throw enough tools at it. Rust gets ownership 100% correct by default. If you're dealing with situations where that 1% matters (complex threading, or decoding hostile data), then it's a much bigger difference than you might think.

- Not counting Rust IDEs (which are only borderline OK by static language standards), Rust tooling is great. Dependency management is solid, linting is good, automatic formatting is good, etc.

- I've been working with nightly and experimental builds of Rust async code, and I think that Rust will soon give C++ a real run for its money in this space. Multithreaded async executors (where you mix "green" threads with OS threads) rely very heavily on precise tracking of who's allowed to mutate what, which Rust is excellent at.

> Finally, if a Rust veteran could let me know: how does Rust deal with general resource management in the presence of exceptions?

Rust does not have exceptions. Instead, it uses `Result` and the `?` operator to propagate errors. Ownership and RAII are 100% idiomatic and fully checked by the same systems as memory management.

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

#118

Post by nicoburns »

coldtea wrote: post #106
gameswithgo wrote: post #92

Earlier quoted context omitted.

your final assertion implies that any new language that is a significant paradigm shift from c++ must be flawed.

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.

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

#119

Post by xfer »

coldtea wrote: post #106
gameswithgo wrote: post #92

Earlier quoted context omitted.

your final assertion implies that any new language that is a significant paradigm shift from c++ must be flawed.

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.

Rust has lambdas, ADTs, pattern-matching and typeclasses(although not as powerful without kinds). These things alone makes a significant paradigm shift than programming in algol style languages. You can just use ARC for every heap-allocated value and rust will still offer a significant advantage compared to C/C++.

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

#120

Post by blattimwind »

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…

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

Of course, if the functional requirement is only "usually works kinda ok", then you don't really need something like Rust.

Post reply on HN