but rust is supposed to make everything better? surely this is just conservative propaganda?
Why I rewrote the mesh generator of Dust3D from Rust to C++
101–110 of 283 posts
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#102Rust is still completely unusable as you can't use dynamic linking as there's no stable ABI.
rust is trash but the kind of person who puts stickers on a laptop thinks it's a good thing, so hey let's drop C++ for it.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#103Earlier quoted context omitted.
> as it’s trying to make _you_ write better code and improve. It’s not necessarily an improvement. When an algorithm processes complex data structures organized in graph or tree, no amount of better code allows to easily implement that in Rust. It’s either slow, or unsafe and hard to implement, or both. Even without trees, consider a simple LRU cache structure. Trivial to implement in most languages by combining link…
> 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…
> criticizing using unsafe in rust and comparing that to C++
In that comment I was mostly criticizing the amount of code. That code doesn’t need to be written in C++. std::list has stable iterators so you can put list iterators to the hash map. This way LRU structure becomes a trivially simple wrapper over std::list and std::unordered_map containers.
Note how Rust developers implemented custom linked list on top of raw pointers, doing manual memory management with Box::into_raw(Box::new(Node::new(k, v)))
C++ implementation doesn’t need a single new/delete, hence much safer than unsafe rust. LRU cache is simple, not too hard to implement correctly in C++ just because it’s very few lines of code.
> it's just that no compiler besides rust will warn you that recursive data structures are hard
In GC languages like C# or Java it’s both easy and safe.
In C++ they can be challenging to implement correctly, but because it’s all unsafe, I get huge amount of help from all levels of the stack. OS debugger, C runtime, C++ standard library, compilers, they all evolved for decades trying to improve life of developers like me writing unsafe programs which use raw pointers. You can implement a recursive data structure without a single new/delete, relying on standard collections for memory management. It doesn’t guarantee pointer safety just like unsafe Rust doesn’t, but at least no need to worry about memory leaks.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#104Earlier quoted context omitted.
> as it’s trying to make _you_ write better code and improve. It’s not necessarily an improvement. When an algorithm processes complex data structures organized in graph or tree, no amount of better code allows to easily implement that in Rust. It’s either slow, or unsafe and hard to implement, or both. Even without trees, consider a simple LRU cache structure. Trivial to implement in most languages by combining link…
> 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 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.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#105Earlier 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…
I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably creep in when you're trying to architect and evaluate and code all at the same time. The kinds of things that make you smack yourself in the face for an hour wasted by the most trivial mistakes.
In addition to my own personal experience this has been incredibly well illustrated to me because I'm overseeing two junior JS devs right now where one starts any new code with "any" types and tries to make Flow happy later and the other starts with real types. The former has a LOT more "this isn't working and I have no idea why, help" moments.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#106Earlier quoted context omitted.
> However, the author is still someone who does not know how to use a programming language and is still bound to not only the mental model of another programming language but also bad practices that lead to problems. Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code. Now it's applied to the other side (…
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.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#107Earlier quoted context omitted.
> Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough. Meshing software is a typical program where you need C++ and where Java is a terrible choice. By nature, meshing makes you play with millions to billions of very small object with mutual interactions. A thing that Java GC absolutely hate. Sorry for the Java fan-boys.
The billion vertex objects might be a nice torture test benchmark for a gc or malloc implementation, but fortunately things aren't so grim in the real world: Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC. In some algorithms, other data st…
> and because malloc/free don't enjoy the bump-allocator style happy case that is used in generational GC's nursery objects.
Performance-optimized use of malloc and free involves using custom suballocators (often called simply "allocators" within user code) which are tailored to the "happy cases" that you know about in your code. A "nursery" of objects that can be bump-allocated and then freed in a single operation is known in this context as an arena/region, and you absolutely can exploit this pattern as part of using malloc/free.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#108Earlier 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.
i think the borrow checker may indeed be a rather large paradigm shift, and im super interested to know if you can get used to it and be as productive as you are in c++ or if it is innately harder. to me it is still hard to work woth but i habe 30 years of being ised to C or garbage collection
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#109Earlier 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…
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.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#110The 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, so I don't have to be.
In practice, with few exceptions, when the type system is refusing to compile something I just screwed up, and I'd better fix my mistake right away. I'd wager that with few exceptions, when Rust is refusing to compile something, you are making a mistake that in C++ would have bitten you down the line.
What you call "fighting the type system", I call "fixing bugs".