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

171–180 of 283 posts

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

#171

Post by andreareina »

ksec wrote: post #149
coldtea wrote: post #79

Earlier 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 (…

>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. I have yet to see anyone jump to Rust on first try and fell in love or could immediately use it in production with no problem. There is a huge learning curve involves. More than often, ( Or pretty much in every case ) They gave up. It was way too compl…

Oh man this is me with so many things. I'll hear about some new-to-me concept, start reading up on it but get stumped by an avalanche of new information and drop it. Months later I'll get the same bee in my bonnet, but suddenly the same articles I found impenetrable parse cleanly.

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

#172

Post by reificator »

larzang wrote: post #105
tsimionescu wrote: post #60

Earlier quoted context omitted.

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

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

I want to agree with you on this statement, but I don't think your anecdote supports it.

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

To me it just sounds like the second junior has a stronger understanding of the language/type system.

Some people come into junior positions because they've learned enough to pass a CS course. Some come into junior positions because they've spent their whole life programming in some way or another and want to get some professional experience on their resume. (And everything inbetween of course)

Now, trying to push the Any dev toward specifying types upfront and watching the results might give you better evidence, and better performance to boot.

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

#173

Post by scott_s »

coldtea wrote: post #155
Tuna-Fish wrote: post #133

Earlier quoted context omitted.

> I don't care if the author is a Rust expert or total newb. Someone who can write a 3D modeler in C++ is someone who should be able to use any new Algol-derived language with ease in short time, regardless if they hasn't seen a line of code in that language before. This statement is absurd. It implies that you believe that there are only cosmetic differences between languages, that no language can ever introduce any…

> This statement is absurd. It implies that you believe that there are only cosmetic differences between languages, that no language can ever introduce any useful new concepts. Well, the fact that you've missed the whole "Algol-derived language" is more absurd to me. Rust, in the end, is C++-streamlined plus fighting with the borrow checker. Not some huge new paradigm shift in how we construct programs (as would be e…

> Not some huge new paradigm shift in how we construct programs

I think Rust is exactly that. It makes memory safety a first-class concern for the language. Thinking about it as "fighting the borrow-checker" is like trying to program procedurally in Java, only using classes as holders of static functions, and feeling like you're constantly fighting against objects.

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

#174

Post by sanxiyn »

steveklabnik wrote: post #138
Const-me wrote: post #127

Earlier quoted context omitted.

Rust only disables these checks very selectively. The idea is good, MS did same in C# since the first version in 2002. Allows to do pointer arithmetic when you really need to, for performance or native interop. What I don’t like about Rust is they use unsafe to workaround language limitations. In C# I have only used unsafe code couple times over the course of 20 years. The standard library doesn’t use unsafe code eit…

One of the reasons the standard library has a lot of unsafe is that the standard library is small, but one of the criteria for being in the standard library is “uses a lot of unsafe.” We’d rather these things get massive visibility. In all my years with Rust, the only unsafe I’ve needed in any of my applications is when doing FFI, and my toy OS. YMMV.

On the other hand, Rust certainly could use a lot less unsafe in the standard library than it currently does. It just doesn't want to.

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

#175

Post by nicoburns »

coldtea wrote: post #156
nicoburns wrote: post #118

Earlier quoted context omitted.

Actually, a lot of the issues that C/C++ programmers have when they are new to Rust seem to be precisely because idiomatic Rust code (which can help to avoid borrow checker issues) is often in a more functional Scheme/OCaml style. Rust is both algol-derived, and ocaml-derived. And arguably the borrow checker creates a new paradigm entirely.

> Actually, a lot of the issues that C/C++ programmers have when they are new to Rust seem to be precisely because idiomatic Rust code (which can help to avoid borrow checker issues) is often in a more functional Scheme/OCaml style. Well, those are not the issues that concern me, or that most (in blogs/HN posts/comments/etc I've read) consider the hard parts. It's the borrow checker.

Right. But if you use a data-oriented FP approach, then you will often avoid borrow checker issues entirely. It is people trying to apply OOP patterns with lots of mutable state that constantly run into borrow checker issues.

The borrow checker might seem like the problem, but the solution is to learn to code in a new style.

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

#176

Post by woah »

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…

Do you use a text editor that highlights errors inline or do you depend on errors in the terminal? Maybe your frustration stems from a lack of tooling.

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

#177

Post by 75dvtwin »

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.

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

I agree with your overall dominant metric. But I come to a different conclusion of what language/libraries bring me there.

To me a type safe language, is a refuge, a comfort zone -- away from the wilderness, unpredictableness and punishing complexity of troubleshooting -- associated with untyped languages.

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

#178

Post by nicoburns »

gameswithgo wrote: post #108
coldtea wrote: post #106

Earlier quoted context omitted.

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

As someone from a JS background, I am far more productive in Rust than C++. C++ makes it really easy to accidentally break something that then takes ages to debug. And using libraries is a massive pain.

However, if you have already learnt to be productive in C++, then I suspect Rust would end up being slightly slower to write the initial code, but not much. And it'd make up for it in ease of refactoring.

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

#179

Post by johnisgood »

__s wrote: post #113

/r/rust thread: https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_... You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community..

I am not going to draw the conclusion that Rust does not have an elitist community from <5 replies, just how you would not want me to draw the conclusion to the opposite based on a handful of people, right?

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

#180

Post by mlthoughts2018 »

ThrowawayR2 wrote: post #168
__s wrote: post #113

/r/rust thread: https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_... You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community..

> You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community. Having read those comments, many of them can be best characterized as politely dismissive, e.g. from the top rated comment " If the author is more comfortable writing this code in C++ it makes sense to use it, but I feel like there is a long way to go to make…

Exactly. A bunch of link spam to reddit or quora doesn’t add up to evidence that the Rust community is reasonable or fair in its evaluation of alternative language choices or trade-offs against other languages.
Post reply on HN