They didn't really do a very good job of selecting marketing examples. The only good one, that shows off creative possibilities, is the knit elephant. Everything else looks like the results of a (granted fairly advanced) search through a catalog of stock footage.
Even search, in and of itself, is incredibly amazing but fairly commoditized at this point. They should've highlighted more unique footage.
An interesting problem for those who're good at e.g., geometric packing problems and space-filling curves.
I wonder about having an optional fill mode with more of a sphere-packing approach. I.e., instead of layering long threads of filament, what if you put down a bunch of dollop-drops in a checkerboard pattern and then staggered successive layers of dollops to fill the gaps?
Prior to computer-generated 3D animation, I can imagine it was very difficult to float and spin vector-arrows in mid-air with enough accuracy to show what goes on without having to resort to reams of explanatory paragraphs.
Eugene Khutoryansky is something of a lesser-known 3b1b that's more focused on physics than math. I found his animations very helpful for building intuition around Maxwell's equations:
Rust allows for higher stakes in terms of risk/reward while guaranteeing many aspects of safety. I'm not sure for this case if the scheduler would benefit from more complex/risky structures but if it did, that'd be a valid example of Rust making things "easier".
Rust definitely makes some easy things more difficult but on the flip side it arguably makes very difficult things easier (to get right with fewer guinea pigs).
When I use the word 'Simple' in e.g., a class name, I usually mean: ~"This is meant to cover the 80% of common cases--I haven't done extensive testing or development on it. If you need to cover something in the remaining 20% of edge and corner cases, you're going to need to write your own more complex code to handle those."
I.e., my code is simple--and that might make your usage complex.
Of course, things can evolve from the original implementation--especially if the code is maintained by a team. What was once 'simple' (from any perspective) can become terribly appendaged yet never renamed.
I think one part of the trick is that you find high-functioning people but in less-overlapping domains.
In one of the more successful teams I was on back in the day, I was a JavaScript developer and was paired with some Flash developers on a project where we had a lot of back and forth calls crossing the boundary. I'd ask them to implement a way for me to call their logic and then they'd ask me for a way to call my logic. We were both super-responsive to the other because neither side had much interest in imposing our preferences in the other's very distinct domain.
On the flip side, we were both quite capable in our own right and thus able to agree on the overall architecture pretty quickly. With some people, you'd probe, "it seems like you should have a way to do X, right?" and they'd respond immediately, "that's definitely not possible, you'll have to work around that". So you'd push, "do you want to check?" but they'd decline so you'd take it upon yourself to dig in and point them to relevant documentation. With these guys, their response to the first question was, "Of course we can do that and you can do Y for us, right?".
That dovetails nicely with: “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” --Upton Sinclair
Even search, in and of itself, is incredibly amazing but fairly commoditized at this point. They should've highlighted more unique footage.