Why I rewrote the mesh generator of Dust3D from Rust to C++ • Hacker News Board

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

#31

Post by sanxiyn » Fri, Mar 15, 2019, 7:06 AM UTC

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 agree D has much better onboarding for C++ programmers, but that's because it's similar, not because it is particularly easy to learn.

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

#32

Post by adamnemecek » Fri, Mar 15, 2019, 7:06 AM UTC

sanxiyn wrote: post #29

edflsafoiewq wrote: post #23

Earlier quoted context omitted.

I feel the opposite. Strong compile-time checks make it easier to modify a system, and especially make it easier for people unfamiliar with a codebase to contribute. Being explicit what the static properties of a system are makes them easier, not harder, to modify. Types serve as explicit documentation for facts about the system that would otherwise have to be reconstructed by every reader. Type checking ensures that…

Hot reloading is the critical feature, and dynamic languages usually have better support for it. (Lisp is a good example.)

Hot reloading doesn’t provide safety guarantees.

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

#33

Post by flukus » Fri, Mar 15, 2019, 7:06 AM UTC

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

I think this is more post-hoc justification than anything else. There seem to be an awful lot of developers concerned about memory safety since rust started becoming trendy and I don't think many of them were coding in ada before rust existed.

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

#34

Post by geezerjay » Fri, Mar 15, 2019, 7:07 AM UTC

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.

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 and best practices while using other languages (core dumps heart attacks), and claims that one of the most important aspects of Rust is that "it's memory safe".

Of course, memory safety is achieved through compiler checks.

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. If someone tries to write broken C or C++ using Rust and Rust's compiler starts to throw error messages pointing out the errors the programmer is making by trying to write broken C or C++ in Rust then obviously Rust is not the problem. It is im fact the solution, and a solution that's being ignored.

Heck, the author praises Rust and it's memory safety, but then proceeds to criticise Rust's compiler because, as he puts it, the compiler will stop you from doing unsafe stuff 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++?

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

#35

Post by TomVDB » Fri, Mar 15, 2019, 7:07 AM UTC

mjburgess wrote: post #22

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…

Static checking burdens the developer with thinking more, etc. -- for sure. The cost is requiring a developer with stronger cognitive abstracting skills. Those people tend to be academics (its almost a definition of a good academic) and also, perhaps, less pragmatic. The ease of programming is not merely a matter of knowledge or experience, base cognitive skills play a very significant part which are largely an at-bi…

> In otherwords: the unable are often snobs.

Oh the irony.

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

#36

Post by adev_ » Fri, Mar 15, 2019, 7:08 AM UTC

sanxiyn wrote: post #26

adamnemecek wrote: post #24

Earlier quoted context omitted.

Most of those langauges don’t have the perf of rust or cpp.

Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.

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

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

#37

Post by sanxiyn » Fri, Mar 15, 2019, 7:08 AM UTC

adamnemecek wrote: post #32

sanxiyn wrote: post #29

Earlier quoted context omitted.

Hot reloading is the critical feature, and dynamic languages usually have better support for it. (Lisp is a good example.)

Hot reloading doesn’t provide safety guarantees.

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

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

#38

Post by ignaloidas » Fri, Mar 15, 2019, 7:10 AM UTC

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.

If you have good manners, Python codebases can easily grow over 100kloc mark. Static type annotations, using descriptive variable and class names, type checks on user input(esp. libraries) makes growth safe and simple.

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

#39

Post by sanxiyn » Fri, Mar 15, 2019, 7:11 AM UTC

adamnemecek wrote: post #30

sanxiyn wrote: post #26

Earlier quoted context omitted.

Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.

Need is relative. If you can get the extra speed, why waste it? Life’s too short to spend it waiting for your computer. And in this case, the author does need cpp speed.

> Need is relative. If you can get the extra speed, why waste it?

Because you can be a lot more productive if you are not extremely constrained by speed.

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

#40

Post by adamnemecek » Fri, Mar 15, 2019, 7:13 AM UTC

sanxiyn wrote: post #39

adamnemecek wrote: post #30

Earlier quoted context omitted.

Need is relative. If you can get the extra speed, why waste it? Life’s too short to spend it waiting for your computer. And in this case, the author does need cpp speed.

> Need is relative. If you can get the extra speed, why waste it? Because you can be a lot more productive if you are not extremely constrained by speed.

That’s a false dichotomy. A language can be both productive and fast.