A co-creator of Pathway here - noticed some inbound from the HN link and was a bit shocked to see the discussion. Of course, Airflow is one of the most widely used technologies out there, even if sometimes considered part of the "legacy" orchestration stack.
For software that is anything other than a modifiable template, stars and forks typically serve users as bookmarks. In the distant past, forks were the prevailing bookmark mechanism. Users who joined Github long after the star functionality was added generally prefer stars over forks for bookmarking. Personally, when evaluating current production use of a project, I index most strongly on the count and type of issues raised.
As for the Pathway framework specifically, if you dive in, the star-gazer demographics is split roughly evenly between: (A) folks, like parent, who heard about the tech one way or another and thought it was cool enough to engage with; and (B) participants of bootcamps and hackathons based on this framework and run in partnerships with top-tier universities globally. The license also restricts forking, and is less welcoming to external contributions than Apache projects.
Author comment: as a fairly common convention, QED immediately after a particular statement means that the statement should be considered proven. Depending on the text, this may either be because the statement (Observation) is self-explanatory, or, the discussion in the text leading up to the statement is sufficient, or, whenever the final statement of a Theorem follows as a direct corollary of Lemmas previously proven in the text.
From the authors: great question. If you take an "easy" task for long-range dependencies where a Mamba-like architecture flies (and the transformer doesn't, or gets messy), the hatchling should also be made to fly. For more ambitious benchmarks, give it a try in a place you care about. The paper is really vanilla and focused on explaining what's happening inside the model, but should be good enough as a starting point for architecture tweaks and experiments.
One of the authors here. I am genuinely thrilled to know someone would like to know what "B" stands for, knowing/expecting that "DH" stands for "Dragon Hatchling"!
A clarification is thus due. As indicated in the github repo: "BDH" stands for "Baby Dragon: Hatchling". Technically, "Hatchling" would perhaps be the version number.
For readers who find this discussion point interesting, I recommend considering for context:
1. The hardware naming patterns in the Hopper/Gracehopper architecture.
2. The attitude to acronyms taken in the CS Theory vs. Applied CS/AI community.
You can, of course, use the almost equivalent scientific-sounding Latin-derived term ("neuromorphic"), buy popcorn, and come back with it for a discussion about memristors.
For software that is anything other than a modifiable template, stars and forks typically serve users as bookmarks. In the distant past, forks were the prevailing bookmark mechanism. Users who joined Github long after the star functionality was added generally prefer stars over forks for bookmarking. Personally, when evaluating current production use of a project, I index most strongly on the count and type of issues raised.
As for the Pathway framework specifically, if you dive in, the star-gazer demographics is split roughly evenly between: (A) folks, like parent, who heard about the tech one way or another and thought it was cool enough to engage with; and (B) participants of bootcamps and hackathons based on this framework and run in partnerships with top-tier universities globally. The license also restricts forking, and is less welcoming to external contributions than Apache projects.