Why I rewrote the mesh generator of Dust3D from Rust to C++
blogs.dust3d.org
Why I rewrote the mesh generator of Dust3D from Rust to C++
1–10 of 283 posts
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#2"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. I know the friction is greater because I am still a Rust learner, not a veteran, but I think this experience stops a lot of new comers, speaking as someone who already conquered the uncomfortable syntax of Rust, coming from a C/C++ background."
To be honest, this article seems somewhat ingenuous. The author wasn't comfortable with Rust, and it seems like he missed the point of the borrow checker. This article will now be circulated whenever Rust is discussed.
Here is a good article that arrives at the opposite conclusion: https://kyren.github.io/2018/09/14/rustconf-talk.html
I've been writing Rust full time for the last month and a half or so and the language is a joy to use. The main difference is that the code I write feels very sturdy and permanent. I've heard other people say the same thing.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#3"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."
This is very much true while learning, and very much not true once you finished learning. It would be very concerning indeed if it were otherwise. As is, it is very concerning for Rust adoption, as this post evidences.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#4"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. I know the friction is greater because I am still a Rust learner, not a veteran, but I think this experience stops a lot of new comers, speaking as someone who already conquered the uncomfortable syntax of Rust, coming f…
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 eventually be money in it, but I am certainly not a convert.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#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.".
These are also the same kind of arguments one could make for wanting to use a weakly typed language instead of a strongly typed language.
Personally I like my types strong and my memory safe...
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#6The 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, error free and perfect at time of production.
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. Coupling components by types propagating through software, increasing time and effort to make changes to your software, increasing the overhead for others to contribute.
In my opinion the dominant metric to evaluate the usefulness of a language's type system should be its overall effect on cost, time spent, productivity, ease of development and capacity to change. Everything else is very subjective or just an aesthetic concern.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#7> 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…
There are always trade-offs. I mean when I'm writing really low-level stuffs (e.g., optimizing matrix multiplication kernels) I frequently find type system annoying. In that case I would definitely prefer C/asm, because they are simply closer to bare medals.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#8"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. I know the friction is greater because I am still a Rust learner, not a veteran, but I think this experience stops a lot of new comers, speaking as someone who already conquered the uncomfortable syntax of Rust, coming f…
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?
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#9The 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 disagree, because Rust compile time checks are not prohibitive. I agree on all other points: you shouldn't try to write perfect software first time, mental overhead is a serious concern, battling type system is bad (but you don't do that in Rust). Overall, Rust is a productive language, especially compared to C++.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#10The 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.