When people start in Rust, they often get into 'fights' with the borrow checker. This can be a source of much frustration, especially for experienced devs who try to use patterns they know from other languages which give them lots of headaches.
This can give off the impression that in order to dev in Rust you need to do overly complex lifetime annotation and/or runtime borrow checking in order to satisfy borrowck.
However, as you get more experienced with Rust, you start to notice that this is not really true at all.
Instead, you realize is that getting into 'fights' with the borrow checker is actually a *symptom* of a deeper problem of ambiguous data ownership in your program.
This is really interesting because it can give you an early forecast of deeper issues on the horizon!
If borrowck is making your life hard, even early on in a project, it's a pretty good sign that *you need to reevaluate data ownership in your code*.
I think this is something that experienced Rust devs sort of do without even realizing it; they've discovered over time that >
fighting borrowck almost never leads to good things, and so they sort of instinctively change things around when they see the first signs of trouble.
And, I think it's really interesting to get this emergent behavior: borrowck was never really designed to be prescriptive, afaik!
Just to clarify what I meant by this last point:
borrowck is designed to check the *correctness* of your code *implementation*, but it was never really meant to be able to tell you whether your overall program *design*/structure is good or not....
And I think it's really interesting that, in practice, the first thing seems to in some way imply the second as well.
An interesting addendum to this, as discussed here
oftentimes, the way borrowck pushes you is not the *only* correct way to do things! perhaps your original idea was actually valid, and it just couldn't be verified b/c borrowck is not smart enough...
Interestingly, the fact that borrowck isn't as smart as a human can be is often a good thing! It means that once you come up with a way to express what you want to do in a way that borrowck understands, it'll be simple enough that a human can more easily verify & work on it too!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Graphics friends: we *really* need to do a better job of talking about color. Right now color science is basically a dark art that never actually gets taught by graphics learning resources unless you seek it out specifically.
Because of this, so many new to intermediate level people (and perhaps even very advanced people if they never needed it for their specific discipline) have basically no idea about color beyond “linear vs srgb”... and they don’t actually understand linear vs srgb either!
“Linear vs sRGB” being such a standard colloquial dichotomy is an example of exactly the issue I’m talking about because it’s used as a simplification to teach to newcomers, but until you have a deep understanding of color science you don’t actually understand what it means!
This funny word is responsible for creating many of those sweet, sweet rim lighting effects we know & love. Understanding it will really help you up to the believability & pop factor of your rendering & lighting!
(THREAD)
The Fresnel effect is actually very simple at its core, and is one of the basic principles of how *ANY* object is lit.
The basic idea is this: the greater the ANGLE of reflection of a ray of light off a surface, the more energy (brightness) that ray will carry!
So, let's explore that image above a little more. We have a light shining onto a surface which reflects the light back at several different angles. Depending on how glossy the surface is, some directions will have more or less rays, and some will end up at the viewer.