<p>Gotta watch this one: <a href="https://x.com/historyinmemes/status/1836050979315216652" target="_blank" rel="nofollow noopener noreferrer" translate="no"><span class="invisible">https://</span><span class="ellipsis">x.com/historyinmemes/status/18</span><span class="invisible">36050979315216652</span></a></p><p>:blobcatgiggle:</p>

<p>Super excited to announce my new lab at <span class="h-card" translate="no"><a href="https://bird.makeup/users/mit_csail" class="u-url mention">@<span>mit_csail</span></a></span> <a href="https://flame.csail.mit.edu" target="_blank" rel="nofollow noopener noreferrer" translate="no"><span class="invisible">https://</span><span class="">flame.csail.mit.edu</span><span class="invisible"></span></a></p><p>I am recruiting new PhD students this year (starting in Fall &#39;25)! If you&#39;re excited about building fast hardware quickly and correctly, come work with me. Some research questions I&#39;m excited about:</p><p>More and more people are excited and invested in building and deploying specialized hardware quickly (see the recent onslaught of ML chip startups).</p><p>* How do we build the next generation of languages and tools to power this revolution?</p><p>* Getting correct hardware designs remains painfully slow. Can we learn from software languages like <span class="h-card" translate="no"><a href="https://social.rust-lang.org/@rust" class="u-url mention">@<span>rust</span></a></span> and design new languages to dramatically improve the process (P.S., I think I know how to do this: <a href="https://filamenthdl.com" target="_blank" rel="nofollow noopener noreferrer" translate="no"><span class="invisible">https://</span><span class="">filamenthdl.com</span><span class="invisible"></span></a>)</p><p>* Even if we make the process of writing low-level hardware designs correct, most people will want to work with higher-level abstractions. How do we build new tools for hardware generation that are correct AND efficient? (I have an angle on this too: <a href="https://calyxir.org" target="_blank" rel="nofollow noopener noreferrer" translate="no"><span class="invisible">https://</span><span class="">calyxir.org</span><span class="invisible"></span></a> )</p><p>* How do we connect our these high-level abstractions to the grueling reality of physical circuits? Can we expose the details of circuits without compromising on user productivity? Can these tools help us and design truly complex systems-on-chip (like the Apple M series)?</p><p>I want to do this work with people who are fundamentally dissatisfied with the existing reality and excited to build new tools and get them used by real people, and positively impact the community by mentoring junior students.</p><p>If any of this exciting, come join my lab!</p>

viva viva https://twitter.com/sVfMoR0PNavIZVR/status/1835640762329174425 https://danbooru.donmai.us/posts/8163976

@pipivovott@post.ebin.club rotte fruity

<p>okay sneaking a compatibility check in `Deref` for `CowStr` seems to do the trick — not sure how that feature got flipped on in one of my crates but oh well.</p><p>this is rubicon&#39;s beautiful &quot;ABI&#39;s fucked&quot; check btw: <a href="https://docs.rs/rubicon/latest/rubicon/macro.compatibility_check.html" target="_blank" rel="nofollow noopener noreferrer" translate="no"><span class="invisible">https://</span><span class="ellipsis">docs.rs/rubicon/latest/rubicon</span><span class="invisible">/macro.compatibility_check.html</span></a></p>

<p>If it takes 10,000 hours to achieve expertise in a skill, you can cut that down to 20,000 hours with the help of AI.</p>

@vaartis@pl.kotobank.ch *shakes you around* get 𝓓𝓪𝓶𝓪𝓰𝓮𝓭 you stupid fruit

<p><span class="h-card" translate="no"><a href="https://types.pl/@bhaktishh" class="u-url mention">@<span>bhaktishh</span></a></span> The way I think of it (probably there are better explanations out there): in impredicative type theories you have a universe that can quantify over all type universes; in a predicative type theory, trying to quantify over the type universe puts you one universe higher.</p><p>System F has impredicative quantification. MLTT with Type:Type has impredicative quantification. CoC has impredicative quantification via Prop.</p><p>Whereas MLTT with a strict universe hierarchy is predicative.</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@dabeaz" class="u-url mention">@<span>dabeaz</span></a></span> It’s baffling that </p><p>class Point(dataclass): x: int; y: int;<br />or<br />class Point(metaclass=dataclass): x: int; y: int;</p><p>doesn’t work. Isn’t that the point of subtyping or submetatyping?</p>