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

#271

Post by renox » Sat, Mar 16, 2019, 8:24 AM UTC

loup-vaillant wrote: post #110

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

That is an oversimplification, very often you know something that cannot be expressed in the types, so escape hatch (cast/unsafe) are useful. That said, if you can wrap around these 'hack' in a 'sane' API, then it's OK if you canno/didn't the result is quite ugly..

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

#272

Post by yoklov » Sat, Mar 16, 2019, 10:04 AM UTC

p0nce wrote: post #90

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'm 100% with you. There is often a debate in the D community how the defaults could have been better: pure, @safe, const by default, no GC by default etc. But not every bit of code need to be perfect. Code must prove its usefulness first and foremost, before the need to be reliable, safe, fast and beautiful even enter the picture. I'd go as far as to say, thinking of a nascent project as something perfect and beauti…

You can still write hacky temp code in Rust, although it does take some experience to get familiar with the ways you can do this without hitting borrow checker errors and etc (well, short of reaching for unsafe, which is generally not a good way to do this).

That said, for getting code written fast, Rust for me has been better than C++ for a while now, even though for most of that I was better at C++ than Rust. The reason for this was largely Cargo, which eliminates the pain points of dependency and build management that plague C++.

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

#273

Post by v_lisivka » Sat, Mar 16, 2019, 10:28 AM UTC

mrfredward wrote: post #222

v_lisivka wrote: post #210

Earlier quoted context omitted.

It's hard to implement unsafe patterns in safe language. It's hard like using ASM with Java, because Java is platform independent language, while ASM is platform dependent language. This impedance mismatch causes problems, which can solved by wrappers. If we are talking about emulator, why not just make clear communication between CPU, RAM, and graphic device? Memory can be split into rows (e.g. by split_at()), so gr…

I can't understand how using split_at() would work...if the CPU and the GPU both have a reference to the RAM, we're still using an Rc >. If the slice gets passed into the CPU and GPU's run() functions, then how does this magical memory manager know what to pass ahead of time? >It's hard to implement unsafe patterns in safe language. I agree with this 100%. And I think that for certain problem domains, rust provides m…

Split memory into pages. Then create two types: OwnedMem, and SharedMem. OwnedMem will own page(s), so access to memory will require no Arc. SharedMem will implement safe protocol to access memory from different threads using Arc or atomic operations. SharedMem must also implement .clone(), so both CPU and GPU will be able to hold it.

> And I think that for certain problem domains, rust provides more safety than you actually want.

If writing of unsafe Rust by hands is hard for you, then write code in plain C, then convert it into unsafe Rust using crust.

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

#274

Post by candiodari » Sat, Mar 16, 2019, 1:21 PM UTC

pjmlp wrote: post #240

mcguire wrote: post #145

" When you implement an algorithm using C++, you can write it down without one second of pause, but you can’t do that in Rust. 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. " Yeah... On my last C++ project, one very productive co-worker kept disabling -Wall, etc., be…

I complain about C's safety all the time, but it isn't as if Dennis and others weren't aware of its shortcomings in that regard. > Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language r…

Perhaps it's more of a case of there being 2 issues:

  domain specific knowledge (e.g. 3d math, usability)

  correct program writing

And you do them in sequence rather than in parallel (and then of course your boss declares phase 2 doesn't get any of your time).

Lots of software engineers really emphasize the second part. But this is like insisting on correct shoelace tying in a shoe factory ... it's nice, but without making a shoe in the first place there is no shoe and no need for shoelaces. And when it comes to choosing between no shoe or badly tied shoelaces ... the choice is clear.

This is why the neverending complaint of software engineers that no-one cares about correctness. Entirely true. You can do without correctness (if there's anything Microsoft taught us), but you cannot do without domain knowledge.

And it's a bit self-serving: guess which one is most often missing in software engineers ?

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

#275

Post by peatmoss » Sat, Mar 16, 2019, 3:27 PM UTC

As someone who never learned C++, I keep hearing about how today’s C++ is much better than the C++ of a few years ago. Can anyone recommend a resource for learning some C++ basics using today’s modern C++?

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

#276

Post by blub » Sat, Mar 16, 2019, 5:39 PM UTC

pcwalton wrote: post #223

blub wrote: post #83

Earlier quoted context omitted.

That's a decent attempt at suppressing OP's message, but the thing which makes all of the above irrelevant is that C and C++ developers are the main groups of developers Rust is targeting. If they can't use the language, the Rust community should perhaps listen to them. Or should have listened to them 10 years ago, because let's be frank: the friction is coming from the fact that Rust can't be changed any more so tha…

> the friction is coming from the fact that Rust can't be changed any more so that it becomes as ergonomic as other languages people are used to. What is your proposal, specifically? It's not that we weren't listening to C++ programmers 10 years ago. We put a ton of effort into making Rust as easy to use as possible. Rather, it's that the problem of memory safety without GC is fundamentally hard. If I could wave a ma…

My only proposal is that the Rust community spends more time coding and less time criticising other languages and praising Rust.

Making proposals about the ergonomics of Rust is way overdue, but I will note that jumping through even more hoops to get correct code is not progress, nor the huge victory that the Rust community hails it to be. Humans use compilers to do work for them, not vice versa.

GC for example is brilliant, Swift is also quite nice. Even if neither solution is applicable, they are both excellent examples on how a user-friendly solution can look like - almost zero user effort.

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

#277

Post by pjmlp » Sat, Mar 16, 2019, 6:21 PM UTC

candiodari wrote: post #274

pjmlp wrote: post #240

Earlier quoted context omitted.

I complain about C's safety all the time, but it isn't as if Dennis and others weren't aware of its shortcomings in that regard. > Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language r…

Perhaps it's more of a case of there being 2 issues: domain specific knowledge (e.g. 3d math, usability) correct program writing And you do them in sequence rather than in parallel (and then of course your boss declares phase 2 doesn't get any of your time). Lots of software engineers really emphasize the second part. But this is like insisting on correct shoelace tying in a shoe factory ... it's nice, but without ma…

Actually, coming from a country where Informatics Engineering is an actual professional title, I think adoption of such practices around the world, instead of allowing somone to name themselves engineer after a six weeks bootcamp would already help a lot regarding the quality of work output.

Any good certified engineers degree takes care that students have a concern for acquiring domain specific knowledge and adopt best practices.

Another thing would be liability, people just need to sue more often IT companies, so that security is actually taken up seriously.

Too many CVEs in the last couple of months? The servers get grounded, product recalls are required from state.

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

#278

Post by pjmlp » Sat, Mar 16, 2019, 6:23 PM UTC

lixtra wrote: post #161

mcguire wrote: post #145

" When you implement an algorithm using C++, you can write it down without one second of pause, but you can’t do that in Rust. 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. " Yeah... On my last C++ project, one very productive co-worker kept disabling -Wall, etc., be…

Depending on the situation a write unsafe fast fix later maybe the more economic approach. Especially if the code is more exploratory, changes a lot and large parts will be finally discarded.

Usually the "later" part never comes, specially in consulting, where there is only one shot to implement each module.

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

#279

Post by pjmlp » Sat, Mar 16, 2019, 6:30 PM UTC

xfer wrote: post #119

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.

Rust has lambdas, ADTs, pattern-matching and typeclasses(although not as powerful without kinds). These things alone makes a significant paradigm shift than programming in algol style languages. You can just use ARC for every heap-allocated value and rust will still offer a significant advantage compared to C/C++.

C++20 has all those things as well, except for pattern-matching expected to arrive by C++23. :)

So if it wasn't for the copy-paste compatibility with unsafe C code, there is already quite a few modern features available in the language.

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

#280

Post by candiodari » Sat, Mar 16, 2019, 8:33 PM UTC

pjmlp wrote: post #277

candiodari wrote: post #274

Earlier quoted context omitted.

Perhaps it's more of a case of there being 2 issues: domain specific knowledge (e.g. 3d math, usability) correct program writing And you do them in sequence rather than in parallel (and then of course your boss declares phase 2 doesn't get any of your time). Lots of software engineers really emphasize the second part. But this is like insisting on correct shoelace tying in a shoe factory ... it's nice, but without ma…

Actually, coming from a country where Informatics Engineering is an actual professional title, I think adoption of such practices around the world, instead of allowing somone to name themselves engineer after a six weeks bootcamp would already help a lot regarding the quality of work output. Any good certified engineers degree takes care that students have a concern for acquiring domain specific knowledge and adopt b…

I'm not saying correct software has no advantages. Quite the opposite: I state and acknowledge the advantages. But it's an amplifier: without something to amplify (which boils down to domain knowledge) it's like owning a billion dollars buried on the moon : interesting, even cool but fundamentally useless.

Software quality has advantages for companies that are very strongly in the "milking their 100% understood market where they have an overwhelming competitive advantage" phase. Large companies. And is between neutral and a disadvantage for nearly everyone else.

That doesn't mean you can't take pride in good software. Or that it isn't an accomplishment. But you want to write quality software for money ? Get a job at Google/Facebook. Better yet, get one at Bank of America, Exxon Mobil or Boeing. Or research it at university.