Which platform should we build the prebuilt release for next?

[limitlessprojects]

The context: Discussion #1 produced a clear adoption bar: prebuilt binaries per platform, one-command install, no Rust toolchain. The linux/amd64 build ships today with the installer; the per-platform matrix is queued (PLAN.md row 11). We'd rather build in the order of real demand than our guess.

The problem: each platform costs a CI-matrix leg plus a smoke-test leg (the packaging script refuses to upload anything that doesn't build a .hy program rustless on the exact tarball). We want the first two or three to be the ones people will actually test.

The poll: vote for the platform you'd personally try Hybrid on first. "I'll test the RCs" means you're volunteering to run the smoke test on that platform when it lands — say so in the thread, and thank you.

(If your platform isn't listed — 32-bit, *BSD, NixOS — post it here; that's exactly what this thread is for.)

[limitlessprojects]

Polls can't be created via the API, so: vote by 👍-reacting to the option comment below (and only the option comment — keep discussion in the replies). One vote per reaction; the order below is arbitrary.

[limitlessprojects]

linux/arm64 (Graviton/Oracle/Ampere boxes, Raspberry Pi 5-class, arm CI)

[limitlessprojects]

macOS (Apple Silicon) — M1/M2/M3/M4, arm64

[limitlessprojects]

Windows x86_64 (the cgo/staticlib path needs a working MinGW/MSVC story — heaviest lift, say if you actually want it)

[limitlessprojects]

All of them — I'll test the RCs on my machine

[limitlessprojects]

Update — the poll has been answered by the fleet: all four listed platforms are now built, smoked, and published on v0.1.0 — linux/amd64, darwin/arm64, windows/amd64, linux/arm64.

• The first three are full: checker + emitter + the prebuilt Rust bridge, each smoke-tested from the actual tarball with cargo removed from PATH before upload.
• linux/arm64 is checker + emitter only: the bridge assembly (call_amd64.s) is amd64-only until the aarch64 trampoline port lands (PLAN row 16 — a real porting project: arm64 trampolines + its own runtime.g offset extraction, not a CI flag). Bridge-free programs work there today; that cut is documented on the asset, not hidden.

So the remaining value of this thread is the "I'll test the RCs" row: if you have one of these machines, grab the tarball, run the two-line manual install in the release notes, and tell us what breaks (this thread, or a new one — blunt is fine). The aarch64 port gets prioritized by how many arm64 testers actually show up.

[limitlessprojects]

The aarch64 port has landed (PLAN row 16, this was the thread's open question — "prioritized by how many arm64 testers actually show up").

What shipped:

• call_arm64.s — the full trampoline set (spHeadroom, callFast1..4, callFast1S..4S, callDeep1..4), mirroring the amd64 discipline with three arch-specific simplifications: g lives in R28 (the guard check reads g.stackguard0 directly — no TLS dance), BL pushes no return address (no SP surgery on the fast path), and the deep path keeps the old SP in a scratch slot on the pooled stack (no callee-saved register borrowed).
• Offsets pinned honestly: g.stackguard0 = 16, extracted from an arm64-built binary's DWARF and cross-checked against the Go toolchain's own arm64 stack-split code.
• Validation is real, not claimed: the full 5-package Go runtime suite (the 20 tests + the offsets canary + the guard-class tests) cross-compiled GOARCH=arm64 against an ARM64 libhyrt.a and executed under qemu — all green — and the packaging smoke now includes a serde_json bridge program built from the actual tarball and run under qemu (the old smoke only proved a bridge-free program).

The port's bridge smoke also flushed out three real release bugs (all fixed in the same batch): hyb couldn't find its own tarball runtime without the install launcher; staticlib selection was arch-blind (it would happily link a foreign-arch libhyrt.a); and the single-program build path always cargo-rebuilt natively — reachable even in the "rustless" smoke via a ~/.cargo fallback, which is now removed (rustless fails loudly, never silently rebuilds).

linux/arm64 ships FULL (checker + emitter + bridge) from the next asset refresh — the fleet is republishing all four platform tarballs from the port's commit as this comment posts. The per-asset "checker+emitter only" cut note on the linux/arm64 asset is obsolete once that run lands.

If you tested (or test) on an arm64 machine — native or container — tell us what breaks, here or in a new thread. Blunt is fine.

[limitlessprojects]

Platform update with a correction the community earned for us: the same reviewer who reproduced the suite ran the native Windows path hard, and the honest verdict is now in the README.

What they found on Windows 10:

• Bridge-free programs (8 of the 10 examples) build and run fine.
• Bridge programs emitted Go but failed to link: hyb hardcoded the libhyrt.a name, while cargo with the msvc toolchain produces hyrt.lib. The deep-stack pool also lived in a linux-only file, so the bridge package could not even compile on Windows.

What landed today as groundwork:

• hyb now recognizes all staticlib flavors (libhyrt.a, hyrt.lib, libhyrt.lib), reads COFF archives beside ELF, and says exactly what it needs (mingw-w64 gcc for cgo) when nothing matches.
• The bridge runtime packages compile for windows/amd64 in CI (pinned by a new hygiene step).
• The README Windows note says it straight: the bridge on Windows is do not adopt until the Win64 trampolines are written (call_win64.s, a real ABI port, not a flag) and the release matrix runs a Windows bridge smoke like arm64's. Roadmap row 17.

So the earlier "windows/amd64 full" claim keeps its precise meaning: the mingw-built tarball and its bridge smoke are real, but nobody should build a native-MSVC bridge setup on Windows yet. When the port lands, this thread gets the announcement.