Whole-known-network
<p><span class="h-card" translate="no"><a href="https://chaos.social/@SDRHoernchen" class="u-url mention">@<span>SDRHoernchen</span></a></span> oh wow that's awful then, I do not want to design in the LGA</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@tef" class="u-url mention">@<span>tef</span></a></span> <span class="h-card" translate="no"><a href="https://unstable.systems/@demize" class="u-url mention">@<span>demize</span></a></span> this is strictly speaking true but a more accurate description of the argument I'm making is that using those things allows you to relegate your interaction with the borrow checker to a simplistic and formulaic way that doesn't have a habit of making you pause while you're in the middle of something else</p><p>re "Python experience", I meant that as in "the Python experience of managing object lifetimes", not that Rust would be literally similar to Python in most aspects</p>
<p><span class="h-card" translate="no"><a href="https://unstable.systems/@demize" class="u-url mention">@<span>demize</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@tef" class="u-url mention">@<span>tef</span></a></span> I think a lot of people use Rust in a flawed way that boils down to "the compiler provides this beautiful and complicated interface, so I should rely on it". this applies to the borrow checker, trait system, higher kinded types, macros, some other things</p><p>you can, in fact, completely ignore all of that and write impactful and high-quality Rust code. the TCP/IP stack I wrote, smoltcp, is like that; it has like one or two places where it does something nontrivial</p>
<p><span class="h-card" translate="no"><a href="https://unstable.systems/@demize" class="u-url mention">@<span>demize</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@tef" class="u-url mention">@<span>tef</span></a></span> well it sounds like the rust things you work on do not require or benefit much from using long-lived (more than one block or even statement) borrowed pointers</p><p>in this case I would simply not use them</p><p>it's a slight performance hit but in many cases nobody cares, and it almost completely frees you from the "oh, the compiler says I can't have nice things" problem you're referring to here</p>
<p><span class="h-card" translate="no"><a href="https://unstable.systems/@demize" class="u-url mention">@<span>demize</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> </p><p>i think you still need some base level of understanding of the borrow checker in order to consistently ignore it through judicious use of clone(), Arc<Mutex<>>, Rc<RefCell<>></p><p>like, even things like "print every element in the hash" involves using a pretty unique api</p><p>it's not really the python experience, even before you get to things like reflection, or dynamic invocation</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> not yet.. but who knows, the ds says "applicable only for 104LGA part" at one point, so there might be more packaging options if infineon ever manages to actually release all of those new usb chips.</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.transneptune.net/@owen" class="u-url mention">@<span>owen</span></a></span> </p><p>Thinking of an elderly friend whose living room is lined with file cabinets, from a career keeping folders of teaching materials, who to this day struggles with the distinction between a "file" and a "document", even though they've been strategically saving documents with iterating file names for years to avoid overwriting old work.</p><p>One barrier to comprehension: the idea of nesting folders working like Matryoshka dolls. This is someone with decades of real world experience with files and folders, and in their real world experience, there's only ever three levels of nesting, a manila in a pendaflex in a drawer.</p><p>Even the suggestion that drawers are nested in cabinets is enough to derail understanding.</p><p>Another, that files exist independent of the program that created them. Trying to find a PDF file after using the scanner, and confused that it doesn't turn up, because they've tried to find it via the Open File dialog in Word. "That is how I get to my files."</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@tef" class="u-url mention">@<span>tef</span></a></span> 40? that's a good deal, sometimes they pay for 20</p>
<p>to be clear, when a recruiter, manager, or ceo says someone is a "genius programmer" or "10x" or similar</p><p>they mean "someone who works 80 hour weeks and we only pay them for 40" </p><p>every time</p>