after the dust settles on `async`/`await` for coroutine `@rule`s (aka: - we agree on a way to annotate

await

types, either with the proposed

await Get[X](...)

syntax, or something else - we agree on the desired syntax for what

await MultiGet(...)

currently does - (maybe) investigate generic

@rule

retry and other control flow operators after @hundreds-breakfast-49010's work to avoid caching exceptions and closing out https://github.com/pantsbuild/pants/issues/8455 - much more ) i was thinking we could look into making a blog post about defining then refining the pants v2 engine syntax since the legendary "`@rule`s as coroutines" PR. i'm not sure what the right audience would be, but the twitter eng blog would be the overachiever option, and if not that then twitter oss has its own smaller blog i think (and website!). i'm thinking we could structure it as (this is just one of many possible approaches) a vague evolutionary timeline (like in a postmortem!!) of our beautiful high-performance type-safe dependency-injected v2 engine alongside the migration to python 3 and mypy (which itself led to higher performance and type safety!!) -- highlighting along the way: 1. incredible work from @hundreds-father-404 for the py3 migration and @enough-analyst-54434's introduction of type annotations for `@rule`s to finally kill the remnants of

Select

declarations - perhapsbriefly mentioning the legacy

datatype

attempt at a type system we shuffled off of (i specifically want to demonstrate that (the pantsbuild org/twitter/the twitter eng effectiveness org) is perfectly capable of dropping shoddy legacy code, it seems like a good thing for PR) 2. the development in phases of the python API in

rules.py

(mentioning e.g.

UnionRule

and

await Get

), along with the decreasing level of difficulty in modifying the rust/python API in

native.py

, including @hundreds-breakfast-49010's recent work on intrinsics to DRY scheduler creation options (this is also a form of greater type safety -- across languages!) 3. pointing to v2 `@console_rule`s that work now to provide value and are super fast, describing the fruits of @fancy-motherboard-24956 and @hundreds-breakfast-49010's work with python format and binary creation tasks and showing interested people what good rules look like 4. look to the future _(brainstorm)_: - describe how remoting works right now thanks to @average-vr-56795 (& many others), maybe mention the hermetic pex creation work with @hundreds-father-404 to drizzle a little limelight on pex (which, incidentally, i know is still used widely at facebook now, even though they open-sourced their own copy of it last year) - point to https://github.com/pantsbuild/pants/issues/7369 packaging pants with a python interpreter (pyoxidizer (used by mercurial) has imports from memory to improve startup time btw), mention statically linking our python/rust ffi (?) - v2 ui!! i don't think the API is stable enough yet to make such a blog post right now (unless anyone disagrees!!), but i'm also going to beg and plead for space to do a hopefully-recurring pants meetup at twitter starting january or february, and i think a blog post like this is just another way we can socialize the fruits of our shared labor. i'm about to make another google doc for a totally separate pex thing -- i'm thinking we could start the discussion in such a google doc for a blog post as well.

this is pretty awesome, thanks. lots of good potential material here, i agree.