I participated in this, have to say it was fun and it's been a thing I've said for years could make (at least) linear algebra lessons more interesting to young people. Shaders are the epitome of "imagery through math", and if something like this was included in my linear algebra classes I would have paid much more interest in school.
Funny now that this is my day job. I'm definitely looking forward to the video by IQ that is being made about this event.
To explain some of the error pixels: the way you got a pixel on the board was by elaborately writing down all operations in details (yes this included even simply multiplications), the goal wasn't if the pixel was correct or not, and depending on the location of your pixel the calculation could be a bit more complex, as long as you had written down your steps to get the result as detailed as possible.
More than likely simple mistakes were made in some of these people's calculations that made them take a wrong branch when dealing with conditionals. Hopefully the postmortem video will shed some light on these.
You raised an issue that the other bulletpoint has the solution for, I really don't see how these are "key differences".
That's what unique_ptr would be for. If you don't want to leak ownership, unique pointer is exactly what you are looking for.
Well yeah, because that's what shared_ptr is for. If you need to borrow references, then it's a shared lifetime. If the code doesn't participate in lifetime, then ofcourse you can pass a reference safely even to whatever a unique_ptr points to.
The last bulletpoint, sure that's a key difference, but it's partially incorrect. I deal with performance (as well as write Rust code professionally), this set of optimizations isn't so impactful in an average large codebase. There's no magical optimization that can be done to improve how fast objects get destroyed, but what you can optimize is aliasing issues, which languages like C++ and C have issues with (which is why vendor specific keywords like
__restrict
exists). This can have profound impact in very small segments of your codebase, though the average programmer is rarely ever going to run into that case.