safety-dance VS sandbox

[2]: https://github.com/rust-secure-code/safety-dance

The most "virtuous"/desirable statement in this topic is probably the "100% safe code now - while being faster than the C version!" on the rust-secure-code/safety-dance entry for miniz_oxide.

According to the rust-secure-code/safety-dance trophy case, their audit left miniz_oxide 100% safe and faster than the C version.

Efforts that don't try to pick winners, but just to help packages that already exist, like Rust Safety Dance and developing tools like Miri. (And that dependency-improving sprint, the name of which eludes me, but which was mentioned in TWIR a while ago.)

I'm similarly iffy on using a parser for something as web-exposed as e-mail which uses unsafe for a performance boost without a thumbs-up from someone like /u/Shnatsel and the Safety Dance.

Since this all happened, the safety-dance project has come into existence, which aims to channel the mob into doing useful things, not just piling onto someone who's got different views on what they want from Rust.

https://github.com/rust-secure-code/safety-dance is always looking for contributors.

I've made a similar game: https://github.com/JMS55/sandbox, and it looks like we've had a lot of the same ideas :)

If you're interested in game development, you may enjoy playing around with Sandbox. It's a game I created where you place sand, water, acid, fire, etc and watch them interact.

> WebGPU is years away to become usable

As a counterpoint, I've been using WebGPU (through wgpu-rs) for the past 1.5 years. It's been a pleasure to use. For instance, here's the CPU-side code for a glow post-process shader using 4 render passes https://github.com/JMS55/sandbox/blob/master/src/glow_post_p....

I've considered implementing Sandbox using wgpu compute sharers (all the rendering is already done with wgpu). The reason I didn't is because I couldn't figure out how to make particles update in parallel - how to handle conflicts between two particles wanting to move into the same position, updating a particle that's supposed to be destroyed, etc. I'd love to get this working however. My last attempt was a the "multithread" branch where I tried to use rayon as a means of prototyping the game using parallel update logic.

Unrelated to a club, but you might enjoy looking at a game I built with Rust + WebGPU https://github.com/JMS55/sandbox.

Counterpoint: https://flathub.org/apps/details/com.github.jms55.Sandbox

Not a GSOC project, but my game Sandbox is open to contributions! https://github.com/JMS55/sandbox

Overflowing the stack: Use a Vec, or Box<[T; N]> (boxed array). A boxed array is a heap allocated array, where the box part just points to some data on the heap, so it's cheap to move around. Both are pretty much equivalent, boxed array is maybe slightly more faster/correct. Note that if you use a boxed array, due to some missing compiler optimizations, you'll probably just get a stack overflow anyways, as the compiler will first store the array on the stack, and then copy it to the heap. This can be solved with some unsafe code, such as in https://github.com/JMS55/sandbox/blob/master/src/heap_array.rs.