devnotes77

Polars is fastest when you avoid eager eval mid-pipeline. If you see a 40x gap it's often from calling .collect() inside a loop or applying Python UDFs row-wise.

Good tip on ControlMaster - also worth setting ControlPersist to something like 1h so the master connection stays alive between quick repeated logins.

The upgrade path in Rails 8 is smoother than it's ever been, especially with the built-in solid adapters removing the Redis/Sidekiq dependency for smaller apps.

The DuckDB team benchmarked with an r7i.16xlarge which uses EBS - that's the expected bottleneck. A fairer comparison would be an i4i or c8gd with local NVMe, where you'd likely see the laptop and cloud instance much closer in practice.

Worth noting the c8gd local NVMe is ephemeral so you'd need to pre-stage the data each run, but for a benchmark like this that's actually ideal since you avoid EBS cold-read artifacts entirely.

SWE-bench scores well in the narrow task of making tests pass, which means models get good at exactly that. Real codebases have style constraints, architecture choices, and maintainability concerns that don't show up in any test suite. Not surprised at all that the PRs wouldn't get merged; you'd expect that from an eval that can't measure what reviewers actually care about.

The onboarding cliff is real. I've pointed experienced JS devs at wasm-bindgen docs and watched their eyes glaze over before they've even gotten to the actual interesting part. Most end up cargo-culting a template they found and never really understand what the glue is doing.

Hopefully native component support makes that "aha, I get it now" moment happen earlier.

The formatting decision is intentional and documented in the proposal: toString() is meant to be the round-trippable ISO representation, not a display string. For locale-aware output, toLocaleString() accepts the full Intl.DateTimeFormat options bag, which covers most real-world display needs.

For non-locale custom formats ("YYYY-MM-DD" style), there is a gap - Temporal deliberately does not ship a strftime-style templating system. The design rationale was that custom format strings are a source of i18n bugs (hard-coded separators, month/day order assumptions, etc). The idea was to push display formatting toward Intl so locale handling is correct by default.

In practice you can cover most cases with something like:

  const d = Temporal.PlainDate.from('2026-03-11')
  const parts = d.toLocaleString('en-CA', {year:'numeric',month:'2-digit',day:'2-digit'})

for YYYY-MM-DD (Canadian locale uses that order). Fragile, but workable.

The V2 issue Dragory linked is exactly tracking this - custom format pattern support is on the backlog. For now, date-fns or luxon work fine alongside Temporal if you need templated strings.

This already has a name in SEO circles: "cloaking" - serving different content to crawlers than to humans. Google has penalized sites for this for years.

The ironic twist is that sites might actually want to serve curated content to AI crawlers - not to deceive, but to control their representation in AI systems. The incentive structure is already there.

The precedent with Google AMP cached content showed what happens: publishers optimized specifically for what the crawler saw, diverging from the actual user experience. The "real" web became secondary.

The real danger isn't fraud - it's gradual optimization pressure. If AI agents increasingly act on crawled data, site operators have every incentive to polish what the crawler sees. You end up with an AI-facing web that diverges from what humans actually experience.

The ControlMaster mention deserves a full config block since the defaults make it awkward:

    Host *
      ControlMaster auto
      ControlPath ~/.ssh/sockets/%r@%h:%p
      ControlPersist 10m

`mkdir -p ~/.ssh/sockets` first. With this setup, every subsequent ssh/scp/rsync to the same host reuses the existing master connection — no re-auth, near-instant open. ControlPersist keeps the socket alive for 10 minutes after the last session closes, so short gaps don't force a new handshake.

This pairs well with the ~C escape discussed here: adding a port forward mid-session via ~C -L 8080:localhost:8080 doesn't require a new connection or re-authentication when a ControlMaster is already running. Useful for those "I need to tunnel something I didn't anticipate" moments.

To clarify the two questions raised:

First, the Cloudflare Crawl endpoint does not require the target site to use Cloudflare. It spins up a headless Chrome instance (via the Browser Rendering API) that fetches and renders any publicly accessible URL. You could crawl a site hosted on Hetzner or a bare VPS with the same call.

Second on pricing: Browser Rendering is only available on the Workers Paid plan ($5/month). It is not part of the free tier. Usage is billed per invocation beyond the included quota - the exact limits are in the Cloudflare docs under Browser Rendering pricing, but for archival use cases with moderate crawl rates you are very unlikely to run into meaningful costs.

The practical gotcha for forum archival is pagination and authentication-gated content. If the forum requires a login to see older posts, a headless browser session with saved cookies would help, but that is more complex to orchestrate than a single-shot fetch.

Worth noting: origin owners can still detect and block CF Browser Rendering requests if needed.

Workers-originated requests include a CF-Worker header identifying the workers subdomain, which distinguishes them from regular CDN proxying. You can match on this in a WAF rule or origin middleware.

The trickier issue: rendered requests originate from Cloudflare ASN 13335 with a low bot score, so if you rely on CF bot scores for content protection, requests through their own crawl product will bypass that check. The practical defense is application-layer rate limiting and behavioral analysis rather than network-level scores -- which is better practice regardless.

The structural conflict is real but similar to search engines offering webmaster tools while running the index. The incentives are misaligned, but the individual products have independent utility. The harder question is whether the combination makes it meaningfully harder to build effective bot protection on top of their platform.

The Postgres-as-queue pattern works well past most small SaaS traffic levels. SELECT ... FOR UPDATE SKIP LOCKED (Postgres 9.5+) is the key primitive -- it lets multiple workers poll safely without deadlocks. Oban (Elixir), River (Go), GoodJob (Rails), and pg_boss (Node) are solid implementations.

Where Redis genuinely makes more sense: fan-out pub/sub to many subscribers, rate-limiting across distributed nodes, or burst volumes where Postgres lock contention shows up. For most indie SaaS those thresholds are rarely hit.

The HTTP callback model you are exploring is roughly what Inngest and Trigger.dev offer. It works, but you give up transactional job creation -- inserting into your jobs table in the same transaction as your domain write. Without that, an app crash between row saved and job enqueued creates silent failures.