Writing a small ray tracer in Rust and Zig • Hacker News Board

Re: Writing a small ray tracer in Rust and Zig

#91

Post by pcwalton » Tue, Jul 02, 2019, 6:19 PM UTC

gmueckl wrote: post #83

pcwalton wrote: post #79

Earlier quoted context omitted.

> To me, this somehow says that most truely interesting problems can only be solved efficiently in Rust using unsafe. Even Vec is implemented with unsafe code under the hood. Rust isn't about not using unsafe code anywhere : it's about encapsulating that unsafe code in reusable abstractions that can be easily audited. This is how essentially all languages work to begin with: unless you're using CompCert, the compiler…

Wait, so how exactly is Rust better than C++ again? If I need to bring my own unsafe code to the party, where is the gain? Especially, if - in your words - "This is how essentially all languages work to begin with". I can build "safe" abstractions in any other language, too, can I not?

No, you can't build safe abstractions in C++. The language lacks the ability to enforce memory safety. Every abstraction you can come up with will have some way to subvert it. In Rust, the abstractions can't be broken without using unsafe, which application logic should never use.

This isn't just a theoretical distinction. Empirically, Rust programs have far fewer memory safety problems than C++ programs do.

Re: Writing a small ray tracer in Rust and Zig

#92

Post by xiphias2 » Tue, Jul 02, 2019, 6:35 PM UTC

CUViper wrote: post #85

xiphias2 wrote: post #18

Earlier quoted context omitted.

I still don't understand why Rayon is not part of the Rust standard library. Rust was created to have easy and safe multithreading on the CPU, and Rayon is the clear winner in this space, for me it feels like something that should be part of Rust.

If Rayon were in the standard library, we would never be able to make breaking changes, whereas in a crate we can possibly release a Rayon 2.0. For instance, we might want to make some low-level changes in the way iterators split their workload, per current experiments in rayon-adaptive: https://github.com/rayon-rs/rayon/issues/616

As somebody else wrote, what's really important is to stabilize a high level parallel iterator API that would probably be common even between Rayon 1 and 2. Of course I see some new APIs, like setting the task splitting policy, but some things, like parallel iteration over a vector and mapping through it should still work.

Java had to change the collection API when it added generics, but it showed that it's possible to split the API contract while improving on the underlying implementation over time. The low level Rayon primitives of course shouldn't be in the standard library name space.

Re: Writing a small ray tracer in Rust and Zig

#93

Post by Const-me » Tue, Jul 02, 2019, 7:08 PM UTC

dahart wrote: post #59

skrebbel wrote: post #22

This is an awesome post. At the risk of shedding it to bikes, one point that the author makes is that Zig's lack of operator overloading makes him write vector math like this: if (discriminant > 0.0) { // I stared at this monster for a while to ensure I got it right return uv.sub(n.mul(dt)).mul(ni_over_nt).sub(n.mul(math.sqrt(discriminant))); } He signs off with: > How do C programmers manage? The answer is simple: w…

> I’m convinced that there’s a proper mathy / lighting-y word for each component in that expression. Sometimes yes, but often no. Frequently this kind of expression is the result of solving an equation, so it’s just an expression. Graphics people often use two approaches for sub-expressions: - You can name them with the same letters that are in the expression, just with the punctuation & operators removed, for exampl…

> Frequently this kind of expression is the result of solving an equation

Some time ago I’ve stopped solving equations, using software for that. Nowadays, when I need them solved, I sometimes don’t even write code, here’s an example: https://stackoverflow.com/questions/1351746/find-a-tangent-p...

Symbolic math software does more “optimizations” than even offline compilers. For example, I have never saw an optimizer which is aware that sin(x)^2 + cos(x)^2 = 1.

Re: Writing a small ray tracer in Rust and Zig

#94

Post by carapace » Tue, Jul 02, 2019, 7:11 PM UTC

fiddlerwoaroof wrote: post #66

dahart wrote: post #59

Earlier quoted context omitted.

> I’m convinced that there’s a proper mathy / lighting-y word for each component in that expression. Sometimes yes, but often no. Frequently this kind of expression is the result of solving an equation, so it’s just an expression. Graphics people often use two approaches for sub-expressions: - You can name them with the same letters that are in the expression, just with the punctuation & operators removed, for exampl…

People say “the two hardest problems in computer science are cache invalidation, naming and off-by-one errors” and we often design systems so that we don’t have to think about cache invalidation and off by one errors (e.g. list.map rather than a for loop). I often wonder if we should think about minimizing how often we name things as well.

Point free form? Ditch your variable names.

> It is very common for functional programmers to write functions as a composition of other functions, never mentioning the actual arguments they will be applied to.

https://wiki.haskell.org/Pointfree

> We are going to use named variables to keep track of the arguments, then write a definition without them.

http://joypy.osdn.io/notebooks/Quadratic.html

Re: Writing a small ray tracer in Rust and Zig

#95

Post by monocasa » Tue, Jul 02, 2019, 7:11 PM UTC

Fronzie wrote: post #72

monocasa wrote: post #46

Earlier quoted context omitted.

Yeah, exactly. YOu know how it becomes a pain to make a const variable that needs some setup in C and C++? This lets you const all the things.

You could assign it from a lambda function.

Which is still more of a pain than "everything's an expression".

Re: Writing a small ray tracer in Rust and Zig

#96

Post by Tuna-Fish » Tue, Jul 02, 2019, 7:50 PM UTC

sitkack wrote: post #86

Tuna-Fish wrote: post #23

Earlier quoted context omitted.

No, there are plenty of safe ways to achieve this in the standard library. The chunks and split families of functions on slices are all designed to do pretty much exactly this.

My comment really upset folks, https://doc.rust-lang.org/src/core/slice/mod.rs.html#991-100... unsafe is the mechanism that GP needs to use to get multiple contiguous mutable borrows. There is nothing wrong with unsafe, it is used to build all of the safe abstractions in Rust.

Everyone here is aware that split\* and chunks\* are built using unsafe. However, reaching for unsafe yourself in this situation is explicitly the wrong thing to do.

The entire point of rust's safety system is that it is possible to build safe things on unsafe foundations because the unsafety can be encapsulated into functions and types that can only be used safely. The safety of these functions then depends on them being bug-free, and the best way this is achieved is by minimizing the total amount of unsafe code in the ecosystem, and sharing it in widely used libraries so that there are enough users and testing to find the bugs.

So no, unsafe is not the mechanism GP needs to, or should use, because the split\* and chunks\* families of functions already exist and do exactly what he wants.

Re: Writing a small ray tracer in Rust and Zig

#97

Post by gameswithgo » Tue, Jul 02, 2019, 8:15 PM UTC

mrec wrote: post #45

I didn't quite grok this bit: > The ability to return values from if expressions and blocks is awesome and I don’t know how I’ve managed to live up until now without it. Instead of conditionally assigning to a bunch of variables it is better to return them from an if expression instead. The example shown (aside from the fact it's assigning a tuple, which is a different point) would naturally be a ternary in C/C++. Do…

There are lots of little nice things:

* you can more easily handle more than 2 options

* you can more easily have a bunch of code in each case

* you don't have a new syntax for the compiler or programmer to have to know about, everything is just consistently an expression

It is nice, and those of us who say that are usually aware of various alternative workarounds with ternaries etc.

Re: Writing a small ray tracer in Rust and Zig

#98

Post by gbmor » Tue, Jul 02, 2019, 11:33 PM UTC

ChrisSD wrote: post #44

gbmor wrote: post #30

Earlier quoted context omitted.

> But the article highlights that discovering the de facto standards is still a challenge for new Rust users -- does anyone know of a well-maintained list of the 10-20 most critical crates that new users should familiarize themselves with after reading The Book? I came across this exact thing recently: https://github.com/brson/stdx

That seems old, especially as error-chain is no longer maintained so I wouldn't recommend it. [0]: https://users.rust-lang.org/t/error-chain-is-no-longer-maint...

I'm new to Rust, so I wasn't aware. Thanks!