cong-or

I built hud after getting burned by blocking in async Rust services during one too many 2am debugging sessions. Blocking on Tokio worker threads can quietly tank throughput and explode p99 latency, all without panics or anything obvious in the logs.

Most profiling tools technically work, but they expect you to reason clearly, correlate timelines, and keep a full mental model in your head. That’s fine at 2pm. At 2am, it’s hopeless. hud’s goal is to reduce cognitive load as much as possible: show something visual you can understand almost immediately.

The UI is modeled after a trans-Pacific night cockpit: dark, dense, and built to be readable when you’re exhausted.

Under the hood, hud uses eBPF to track scheduling latency—how long worker threads are runnable but not running. This correlates well with blocking (though it’s not a direct measurement). You can attach to a live process with no code changes and get a live TUI that highlights latency hotspots grouped by stack trace.

The usual suspects so far: std::fs, CPU-heavy crypto (bcrypt, argon2), compression (flate2, zstd), DNS via ToSocketAddrs, and mutexes held during expensive work.

Tokio-specific (worker threads identified by name). Linux 5.8+, root, and debug symbols required.

Very open to feedback—especially around false positives or flawed assumptions. Happy to answer questions.

https://github.com/cong-or/hud

I built hud after getting burned by blocking in async Rust services during one too many 2am debugging sessions. Blocking on Tokio worker threads can quietly tank throughput and explode p99 latency, all without panics or anything obvious in the logs.

Most profiling tools technically work, but they expect you to reason clearly, correlate timelines, and keep a full mental model in your head. That’s fine at 2pm. At 2am, it’s hopeless. hud’s goal is to reduce cognitive load as much as possible: show something visual you can understand almost immediately.

The UI is modeled after a trans-Pacific night cockpit: dark, dense, and built to be readable when you’re exhausted.

Under the hood, hud uses eBPF to track scheduling latency—how long worker threads are runnable but not running. This correlates well with blocking (though it’s not a direct measurement). You can attach to a live process with no code changes and get a live TUI that highlights latency hotspots grouped by stack trace.

The usual suspects so far: std::fs, CPU-heavy crypto (bcrypt, argon2), compression (flate2, zstd), DNS via ToSocketAddrs, and mutexes held during expensive work.

Tokio-specific (worker threads identified by name). Linux 5.8+, root, and debug symbols required.

Very open to feedback—especially around false positives or flawed assumptions. Happy to answer questions.

https://github.com/cong-or/hud

Interesting framing. The article makes a compelling case that we're seeing the hangover from 14 years of ZIRP-fueled hiring rather than an AI apocalypse.

But I'm curious what people think the equilibrium looks like. If the "two-tier system" (core revenue teams + disposable experimental teams) becomes the norm, what does that mean for the future of SWE as a career?

A few scenarios I keep turning over:

  1. Bifurcation - A small elite of "10x engineers" command premium comp while the majority compete for increasingly commoditized roles                                                       
  2. Craftsmanship revival - Companies learn that the "disposable workforce" model ships garbage, and there's renewed appreciation for experienced engineers who stick around                 
  3. Consulting/contractor becomes default - Full-time employment becomes rare; most devs work project-to-project like other creative industries                                              
                                                                                                                                                                                              

For those of you 10+ years into your careers: are you optimistic about staying in IC roles long-term, or does management/entrepreneurship feel like the only sustainable path?

The toxicology is pretty damning: codeine without morphine in stomach contents means someone crushed up Tylenol-3 and gave it to a 12-day-old baby. That's not a metabolic quirk—it's homicide. Koren's "ultra-rapid metabolizer" theory provided cover, and his research went on to clear 17 other caregivers in similar deaths. How many of those were actually murdered infants?

2035: Apple takes 30% of my Patreon, Google matched it through their "Competitive Parity Agreement," and the EU fined them both €2 billion which they paid in 45 minutes of revenue then raised fees to 32% to cover legal costs.

The real innovation was convincing us this was inevitable.

Surprised London holds this position given the cost of living. Housing alone eats such a massive chunk of salary that I'd expect talent to gravitate toward cities where their equity/salary goes further. How do early-stage startups compete for engineers when rent is £2k+ for a one-bedroom?

Fair enough—I wasn’t imagining tiny compass-wielders. I was thinking more about whether the structure of a geometric construction might map to something computationally useful, like exact arithmetic systems (CGAL-style) that preserve geometric relationships and avoid floating-point degeneracies.

But for a constant like φ, you’re right—(1 + sqrt(5)) / 2 is trivial and stable. No clever construction needed.

Is there a computational advantage to constructing φ geometrically versus algebraically? In rendering or CAD, would you actually trace the circle/triangle intersections, or just compute (1 + sqrt(5)) / 2 directly?

I’m curious if the geometric approach has any edge-case benefits—like better numerical stability—or if it’s purely for elegance.

What’s the latency on a hostcall? A PCIe round-trip for something like File::open is fine—that’s slow I/O anyway. But if a println! from GPU code blocks on a host round-trip every time, that completely changes how you’d use it for debugging.

Is there device-side buffering, or does each write actually wait for the host?

At ~$100B in AI funding, the question isn’t capital—it’s physical constraints.

Data centers need power (H100s are ~700W each), and recent capacity additions were mostly pre-allocated. Chip supply is also constrained by CoWoS packaging, not fab capacity, and expansions take years.

If power, packaging, and GPUs are fixed in the near term, does $100B mostly drive inflation in AI infrastructure prices rather than materially more deployed compute? Are we seeing the real cost of a usable GPU cluster rise faster than actual capacity?

Has anyone modeled what $100B actually buys in deployable compute over the next 2–3 years given these constraints—and whether that figure is shrinking as more capital piles in?

The 160k → 90k LOC reduction is nice, but the parallel rollout is the more interesting part. Running Rust alongside the C++ version and using differential fuzzing to check equivalence is a lot more realistic than “rewrite and pray.” You get incremental validation with the old system as a fallback. Curious how long they ran both before cutting over.

Binary size is a real concern on the client side. On servers the Rust stdlib overhead usually doesn’t matter, but when you’re shipping to billions of mobile devices, every KB counts. Good to see they invested in build tooling instead of just accepting the bloat.

The 2.5 days to scan 100 million cutouts is impressive, but what's more interesting is the approach: rather than training a model to recognize specific categories of objects, AnomalyMatch flags things that don't fit learned patterns. It's fundamentally different from classification.

This "anomaly detection" framing seems underexplored in astronomy compared to other fields. In fraud detection or infrastructure monitoring, flagging outliers is standard practice. The fact that this is the first systematic anomaly search of the Hubble archive suggests there's probably low-hanging fruit in other telescope datasets too.

The "several dozen objects that defied classification altogether" is the most interesting part. Those are either noise, errors in the pipeline, or genuinely new phenomena. Would be curious what the false positive rate looked like during manual review.