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

11–20 of 283 posts

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

#11

Post by fulafel »

jsiepkes wrote: post #5

> 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. While anyone is obviously free to use any language he or she likes the whole article comes across to me as someone arguing why they dont want / need seatbelts: "They constrain my movement, I'm a good driver, etc.". Thes…

Strong typing and memory safety are compatible with his wants. It's just that Rust isn't it. Any of Clojure, F#/C#, Python, or Go might be good here. (Ok, the nil-punning might make the strong arguable on Clojure's point... but otoh you have spec)

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

#12

Post by gmueckl »

Doing game dev and digital content creation in anything but C++ and some python is simply a fool's errand. Any decent software in this area needs to use libraries written in C++ to have even a remote chance of being successful. These libraries are often written in ways that makes wrapping them for other languages impossible or at least force the exclusion of some desirable features in the bindings.

In other words, C++ is utterly entrenched in that space like Fortran is for HPC.

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

#13

Post by petre »

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…

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.

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

#15

Post by gmueckl »

adamnemecek wrote: post #10
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…

> capacity to change Good luck making changes to a 100kloc Python codebase.

You could perhaps start by adding type annotation. They are not perfect, but they help.

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

#16

Post by nraynaud »

adamnemecek wrote: post #8
nraynaud wrote: post #4

Earlier quoted context omitted.

XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. I have been studying rust for embedded since January and I am not really impressed by what I have seen. I am mostly hacking around the deficiencies of the libraries, the crazy organisation of the stack, and the issues with the community. I am sticking with rust for now because I feel like there is a bandwagon and there might event…

> XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. This argument could be applied to anything. What's crazy about Rust stack organization? What are the issues with the community?

Basically you have some kind of hierarchy of crates according to the abstraction level, and those crates are owned by some loose organisation.

The trick is that the those crates are new and there is only very few MCU features exposed in them (and modern MCUs are so "big" that there is no real hope to get out of the situation quickly), so when you're doing a project, you either have to send a PR upstream and have it die there immediately or argue for days before it dies, or you have to fork the crate yourself. I couldn't find a way to add code in the namespace of a crate without actually re-compiling it.

It was extremely naive to split the crates horizontally and have only a limited group of people able to access the register they want to use, and not expose some kind of extension mechanism.

some examples: STM32F103 doesn't expose DMA, there is no provision for async SPI, no provision for changing the speed of any communication device (nor any bus for that matter). Which we could attribute to the thing being new, but drivers are already being written in such a way that thing are getting calcified like that, and the task of exposing all the functions of the MCU in rust is infinite, it has to be open to outsiders and that involve having a different slicing of API, and always making sure that from any configuration we can call release().

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

#18

Post by sanxiyn »

adamnemecek wrote: post #8
nraynaud wrote: post #4

Earlier quoted context omitted.

XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. I have been studying rust for embedded since January and I am not really impressed by what I have seen. I am mostly hacking around the deficiencies of the libraries, the crazy organisation of the stack, and the issues with the community. I am sticking with rust for now because I feel like there is a bandwagon and there might event…

> XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. This argument could be applied to anything. What's crazy about Rust stack organization? What are the issues with the community?

There are lots of issues with using Rust for embedded development, most of them long standing, which are often felt to be neglected, and some suspicion that progress is slow because it is not the highest priority for decision-making people. https://github.com/rust-embedded/wg/issues/64 details some of these technical issues. Personally issues with Cargo are the most pressing, and math/compiler_builtins is very annoying.

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

#19

Post by adamnemecek »

gmueckl wrote: post #15
adamnemecek wrote: post #10

Earlier quoted context omitted.

> capacity to change Good luck making changes to a 100kloc Python codebase.

You could perhaps start by adding type annotation. They are not perfect, but they help.

Too little too late.

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

#20

Post by isatty »

petre wrote: post #13
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…

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.

I believe you’ve not been on the receiving end of a 17 page compiler error while trying to compile a template heavy app, because you forgot to put an &.

The important part is to realize _why_ you’re fighting the compiler as it’s trying to make _you_ write better code and improve.

If you find non issues being reported by the compiler please report it and make it better for all of us too!

Post reply on HN