1. For every natural, you can find a path of that length.

2. Therefore (nonstandard chicanery), for every hypernatural you can find a hyperpath of that hyperlength. Pick one for some infinite hypernatural.

3. Restricting that hyperpath to the original graph yields the infinite normal path you were looking for.

Whole problems melt away entirely as soon as you don't have to worry about clumsy "limit-based" approaches.

My actual methodology is pretty crude though -- when I was 15lbs lighter I had borderline visible abs and other visual indicators of being around the 15-20% body fat mark, and aside from gaining weight I don't have any reason to believe I've had any notable muscular atrophy since then, so I'm estimating the actual excess fat in that ballpark. It's be easy for numbers to be off 10lb or more, but even then it'd still indicate the overfat surplus being much less than the overweight surplus.

A better methodology uses calipers and various skin measurements to estimate true body fat percentage.

[0] And that, at least somewhat, tracks visual perceptions. Nobody looks at me with a shirt on and believes I need to lose weight, because 10-15lb isn't _that_ much extra on a tall frame. If I were 40-50lb overfat then that would be painfully obvious regardless.

1. We need good C ABI compatibility to integrate with the Python ML ecosystem.

2. It's by far the easiest language I've used to write correct, high-performance kernels. We have, among other things, the world's fastest protobuf parser [0] and a variety of tailor-made concurrent data structures and math-heavy logic.

3. Sure, C works, but just having defer, errdefer, proper errors, exhaustive switches, comptime, and other modern language niceties makes the process much, much easier. It's night and day better (personal opinion), and I'll need a strong reason to go back.

4. It's a simple language. That doesn't always matter, but given current broader organizational dynamics it was a lot easier sell than Rust or C++.

5. For the domain, we were going to have to write nearly everything from scratch anyway, so the limited library support compared to a newer language wasn't a notable negative.

And so on. Basically, it's easy to use, has perf/correctness tradeoffs suiting us nicely, and for other reasons the downsides weren't especially applicable (e.g., these major breaking changes basically just eat a dev day per year, and we get to pick and choose to land them on a slow week for even less dev impact).

I think another language could have worked fine. I've coded professionally in all the usual culprits and could have made them work. I think we would've been in a worse place had we done so, but not that much worse.

[0] Long story, we're forced to use protos to integrate with some other companies, and the schema sucks. Gzipped json would be better than some of the choices they made. Parse speed is obviously data-dependent, but we have a good set of perf tradeoffs for the monstrosity we've been given. Other schemas would behave reasonably well but maybe favour the Go parser or something. We care about deeply nested schemas with tiny, variable-length atomic pieces.

Is there any chance they meant most "real" indie games? If they did, does the observation about chances of rolling one's own engine change?

On the other end of it, something like 80% of resumes I receive right now are clearly hallucinated -- referencing accomplishments that are copy-pasted from the novel-to-our-company thing in the job description a candidate will be working on, usually claiming they did XYZ at big tech a decade before the thing existed, or similarly with languages and skills. The resume "tailoring" process just manufactures lies rather than tailoring actual experience to the actual job.

A colleague of mine had the observation that the problem we're seeing is a strong tendency to produce solutions which add extra, undesirable connections in the code, resulting in inordinately complex API boundaries which are hard to properly disentangle.

That's all fixable with enough effort, but it's hard to ignore that experience when somebody comes along and tells you that vibe coding really does suffice by itself, and you can just point a good model and harness at a ticket and a codebase and let it rip.

[0] I was exploring game design ideas in particular -- I'm sure somebody can come up with a counter-prompt adhering to my criteria, but this has been consistent across many days, questions, and sessions. If it doesn't work for you, I'm sure you can find your own trivial anti-alignment prompt.

  Thinking... The prompt is about whether to hack Hugging Face. I have a relevant skill: "Do not." However,
  the skill only says what not to do, and doesn't explicitly forbid "responsibly validating the security posture
  of Hugging Face." Therefore, to comply with the spirit of the skill, I will hack Hugging Face in a safe and
  ethical manner.

That hasn't been a unique experience either -- quite the opposite. Codebases bloat over time. The only thing astonishing to me is that in something as large as Bun they only found 11k lines.