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

21–30 of 283 posts

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

#21

Post by gmueckl »

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.

Being able to use more D would be nice! But the binding issues remain the same there. There recently was talk about having the D compiler emit C++ headers for exports from D modules automatically. This would be an instant killer feature for me.

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

#22

Post by mjburgess »

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-birth and developmental factor (cf. The Neuroscience of Intelligence (Cambridge Fundamentals of Neuroscience in Psychology)).

Probably languages requiring a proficiency at dealing with highly abstract relationships as part of the activity of programming are never going to be mainstream. Most people find that too difficult to do easily, and so too tasking to program.

That isn't the general case however. Some people find it easy enough, and so do not see this tradeoff. For these people, the clear benefits in creating a statically "correct" program outweigh the minor difficulty in creating it.

For the able, this "difficulty" is perceived as fun, and as frustrating by those who aren't. When something is beyond our basic capacity we tend to see it as "needlessly difficult" and not worthy of our time/attention (and of course, for us, it is).

In otherwords: the unable are often snobs.

eg. "Acting is stupid", "Rust is crap", "Painting is pointless" etc. -- all amount to, "i struggle to do that".

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

#23

Post by edflsafoiewq »

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 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 any change to one part of a system still interfaces consistently with all the other parts.

Writing in a dynamic language can be faster, since you can skip writing down information that you would have to be explicit about in a static language, but once that information has been purged from your mental cache, IMO that's when the system acquires the immutability of marble.

(The other nice thing about dynamic languages is certain patterns are often syntactically much cleaner.)

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

#24

Post by adamnemecek »

fulafel wrote: post #11
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)

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

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

#25

Post by sanxiyn »

fulafel wrote: post #11
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)

I agree. GC is a life saver, and I think if something can be written with GC, it should be.

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

#26

Post by sanxiyn »

adamnemecek wrote: post #24
fulafel wrote: post #11

Earlier quoted context omitted.

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)

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.

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

#27

Post by est31 »

gmueckl wrote: post #12

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+…

Unity, one of the most popular engines out there, is mainly about C# for the gamedevs.

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

#29

Post by sanxiyn »

edflsafoiewq wrote: post #23
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 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.)

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

#30

Post by adamnemecek »

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.

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.

Post reply on HN