From a senior to future senior Hackers

Latest Posts

View all posts →

Latest Videos

View all videos →
Rust SSR vs Next.js: Cold Starts and Type Errors, Tested

Rust SSR vs Next.js: Cold Starts and Type Errors, Tested

A hands-on comparison of Rust server-side rendering and Next.js on two axes: cold-start time and type-error handling. The harness runs two routes in each stack — an HTML page with a 200-item list, and a signup POST that parses and validates JSON — then measures process spawn to first 200 OK, 100 runs per configuration, p50 with p95 and min–max recorded. Three separate numbers are kept separate on purpose: the Rust release binary, the Next.js standalone production server, and the Next.js dev server compiling a route on first request. Only two of those are production measurements. The second half compares what each type system stops. Rust rejects a non-exhaustive match at compile time and Serde rejects malformed payloads at the boundary. TypeScript runs a check in next build, but ignoreBuildErrors turns it off, as casts assert shapes without verifying them, and an untyped JSON body has no type at all. One caveat the post is explicit about: Topcoat itself was not benchmarked, because it couldn't be installed. The Rust figures describe axum with askama, the plainest HTTP-plus-template stack matching the shape the report describes — so treat them as the cost of the language and rendering model, not of any specific framework runtime. Full harness, commands and caveats: https://hackyjs.com/posts/testing-topcoats-rust-ssr-against-nextjs-on-cold-starts-and-type-errors

rustnextjsssr
Why the Same Prompt Costs More in Japanese: Tokenizer Variance and Cost Modeling

Why the Same Prompt Costs More in Japanese: Tokenizer Variance and Cost Modeling

Same support question, different invoice. In the post's six-locale example under cl100k_base, the same billing content costs 1.00x in English, 2.07x in Japanese, and 6.13x in Burmese. This short shows the tokenizer mechanics behind that spread: corpus frequency sets BPE merges, thin coverage falls back to bytes, and every byte becomes a token. It also covers the reproducible per-encoding harness and why swapping models doesn't fix a vocabulary-allocation problem. Read the full write-up: https://hackyjs.com/posts/why-the-same-prompt-costs-more-in-japanese-tokenizer-variance-and-cost-modeling

tokenizationllm-costsmultilingual
Workload Placement When Data Center Permits Become a Supply Constraint

Workload Placement When Data Center Permits Become a Supply Constraint

Permitting delays, zoning lawsuits and fast-tracked approvals don't stay in the policy section — they show up as quota ceilings, SKU gaps per availability zone and committed-capacity contracts inside your deployment pipeline. This short walks through the placement playbook from the post: why entitlement, energization and silicon run on three different clocks, how to probe instance-type offerings per zone instead of per region with a read-only Describe call, and why an absent offering is a topology fact while exhausted capacity is only a scheduling fact. The ranges quoted for entitlement, energization and silicon are rough industry-typical figures used as directional guidance, not figures from the cited reports. The reported items are the UK moving to fast-track data center approvals, the AVAIO suit against Pulaski County over new digital infrastructure rules, and an opinion piece arguing standards should underpin responsible AI data center development. The link between permit friction and SKU scarcity in existing regions is the author's inference, flagged as such in the post. Full write-up: https://hackyjs.com/posts/workload-placement-when-data-center-permits-become-a-supply-constraint

data-centerscloud-infrastructurecapacity-planning