PortMortem
Discord
A Hackathon Raptors event · 2026

Port Mortem

Pick a real repo. Pick a new language. Prove the rewrite holds up.

Dates
Jul 31 – Aug 03
Format
72h · Online
Entry
Free
Prize pool
$1,800
Join the Discord Read the brief
13,044
unsafe blocks at the Bun Zig→Rust merge
99.8%
Linux x64 test-pass rate Bun claimed at merge
1B
lines of C/C++ Microsoft targets to port to Rust by 2030
72h
to build a port that actually behaves like the original
01 / The problem

The problem

In May 2026, Bun merged a 960,000-line, 2,188-file rewrite from Zig to Rust in six days, generated mostly by Claude Code agents.12 At merge it had a 99.8% Linux x64 test-pass rate — and 13,044 unsafe blocks.3 For comparison, Astral's uv (a comparable systems-level Rust project) has 73.

Then people noticed something else: parts of the original Bun test suite had been edited to make the Rust port green.4

The "rewrite it in Rust" meme has officially graduated to corporate strategy. Microsoft published a goal of porting one billion lines of C/C++ to Rust by 2030, AI-assisted.5 DARPA's TRACTOR program is funding the same direction.6 Microsoft's TypeScript compiler is being rewritten from TypeScript into Go for a ~10× speedup, due GA in 2026.7 Discord's Go-to-Rust migration of their read-states service is now five years old and still cited in every distributed-systems hiring loop.8

Generating a cross-language port is now trivial. Anyone with Claude Code and a weekend can produce something that compiles. Producing a port that actually behaves like the original — same edge cases, same concurrency semantics, same failure modes, with the original test suite untouched — is the open problem.

Port Mortem is a 72-hour hackathon. Pick a real public GitHub repo in language X. Rewrite it in language Y. Prove the original test suite still passes, unmodified. Survive a differential fuzz session. Show your unsafe count. Defend your architectural decisions to a human.

We're not against AI-assisted porting. We're against the version of it that ships 13,000 unsafe blocks and edits the tests on the way out.

You have 72 hours.

02 / Why now

Why now

The “rewrite it in another language” phase of the industry stopped being a meme in 2025 and became corporate strategy in 2026.

Microsoft is rewriting the TypeScript compiler in Go (~10× speedup), and has stated a goal of porting one billion lines of C/C++ to Rust by 2030, AI-assisted.57 DARPA's TRACTOR program is funding C-to-Rust translation at scale.6 Anthropic acquired Bun and shipped a 960,000-line Zig-to-Rust rewrite in six days using Claude Code.12 Astral has rebuilt the entire Python tooling stack (ruff, uv, ty) in Rust and is replacing each tool people use daily.10 Discord's five-year-old Go-to-Rust read-states migration is still the canonical reference for “GC vs predictable latency” in distributed systems interviews.8 Cloudflare's Pingora replaced NGINX with Rust at 40M+ req/sec.11

The technical capability is here. The cultural permission is here. What's missing is the rigor.

Bun shipped 13,044 unsafe blocks at merge and edited tests on the way out. Microsoft's billion-line goal assumes the AI-generated ports are correct without specifying how anyone will verify that at scale. Most “we rewrote X in Y” weekend posts ship without test parity, without differential fuzzing, without honest benchmarks.

This is the gap. Generating ports is solved. Proving they work is the open problem.

That's the hackathon. 72 hours. Real repo. Real test suite. Real differential fuzzing. Real signed Evaluation Protocols at the end. No edited tests. No unsafe-everywhere. No “compiles but doesn't actually behave like the original.”

Languages die. Code doesn't.

03 / Eight tracks

Eight tracks

Eight source-to-target pairs. Pick one.

Source ↓ · Target → → Rust→ Go→ Zig→ Other
C A G
Zig B
Python D
Go E
TypeScript C
JavaScript F F
Open (X→Y) H

Filled cell · jumps to that track. Each track is anchorable as #track-a through #track-h.

01 / 08
A · C → Rust

The DARPA direction

  • Difficulty Hard
  • Team 2–3
  • Pool ~6 repos
  • LOC 3–8k

Memory-safety migration backed by Microsoft and DARPA. c2rust produces mostly unsafe — the interesting work is what comes after.

  • Passes the original C test suite, unmodified, ≥99%
  • Reduces unsafe count to under a documented threshold versus the source line count
  • Catches at least one latent bug in the original via differential fuzzing
  • Handles error paths idiomatically — Result, not errno translated
Systems engineers · Security teams · Compiler folks
02 / 08
B · Zig → Rust

The Bun story

  • Difficulty Hard
  • Team 2–3
  • Pool ~4 repos
  • LOC 2–8k

The Bun-shaped problem, solved without 13,000 unsafe blocks.

  • Targets a real Zig project under 8k LOC with a meaningful test suite
  • Preserves allocator behavior and explicit error sets in idiomatic Rust
  • Documents every unsafe block with a rationale in the source
  • Beats the original on at least one benchmark without sacrificing test parity
Systems engineers · Language implementers · Runtime authors
03 / 08
C · TypeScript → Go

The Microsoft TS7 direction

  • Difficulty Medium
  • Team 1–3
  • Pool ~5 repos
  • LOC 3–8k

Native compilers and tools for the JS ecosystem. The defensible alternative to Rust.

  • Starts measurably faster than the TypeScript original (cold + warm)
  • Preserves API compatibility for downstream consumers
  • Exposes a clean Go module structure that idiomatic Go reviewers would accept
  • Survives the original Jest/Vitest/Mocha suite when bridged through a thin adapter
Tooling authors · DX engineers · Platform teams
04 / 08
D · Python → Rust

The Astral playbook

  • Difficulty Medium
  • Team 1–2
  • Pool ~7 repos
  • LOC 2–6k

The Astral lineage. Python tools that earn their right to be in Rust.

  • Targets a Python tool with a published test suite (linter, formatter, CLI, parser)
  • Matches or exceeds 10× speedup on a documented workload
  • Compiles to a single binary, no Python runtime required
  • Reports honest p99 latency and RSS — not just hot-loop throughput
Python tooling maintainers · Developer-experience engineers · CLI builders
05 / 08
E · Go → Rust

The Discord canon

  • Difficulty Medium
  • Team 2–3
  • Pool ~4 repos
  • LOC 3–8k

GC pauses vs predictable tail latency. The original “is GC negotiable?” story.

  • Demonstrates measurable p99 latency improvement on a representative workload
  • Preserves concurrency semantics under a soak test
  • Documents memory footprint reduction with a methodology a senior SRE would accept
  • Survives a shadow-traffic-equivalent differential test against the Go original
SREs · Backend engineers · Platform teams
06 / 08
F · JavaScript → Go or Rust

Runtime modernization

  • Difficulty Easy–Med
  • Team 1–2
  • Pool ~6 repos
  • LOC 2–5k

A Node-only tool, shipped as a static binary nobody needs node_modules to run.

  • Eliminates the Node runtime dependency entirely
  • Matches the original CLI surface (flags, exit codes, stdout/stderr layout)
  • Passes the original tests when re-pointed at the new binary
  • Reduces startup time on a documented benchmark
DevTool builders · CLI maintainers · Open-source authors
07 / 08
G · C → Zig

The other memory-safety answer

  • Difficulty Hard
  • Team 1–2
  • Pool ~3 repos
  • LOC 2–6k

Zig's allocator discipline and explicit error sets, fixing lifetime bugs the C original has carried for years.

  • Translates a real C library under 8k LOC into idiomatic Zig
  • Exposes the same C ABI for downstream consumers
  • Surfaces and documents at least one allocator-misuse bug in the original
  • Passes the original test suite via the preserved ABI
Systems engineers · Embedded folks · Language enthusiasts
08 / 08
H · Open Pair (X → Y)

Surprise us

  • Difficulty Variable
  • Team 1–4
  • Pool Any defensible
  • LOC 2–8k

Ruby → Rust. PHP → Go. COBOL → Go. Java → Kotlin. Elixir → Gleam. Pick a defensible pair, justify it in your README.

  • Solves a real problem the original language poorly serves
  • Maintains behavioral equivalence under the original test suite
  • Documents the migration rationale — performance, safety, ecosystem, hiring
  • Reads as idiomatic in the target language to a senior reviewer
Polyglot engineers · Legacy modernizers · Open-source maintainers
04 / Deliverables

Deliverables

After 72 hours, we want a working port. Not a transpiler proof-of-concept. Not a slide deck.

A working port

The original repo's full test suite, unmodified, runnable against your code. Hashed at kickoff, verified at submission. If the tests diff from what we hashed, you forfeit Test Parity points.

Actual behavioral equivalence

Not just a successful compile. Show us a differential fuzz session. Show us the diff in CLI outputs on a shared input set. Show us the benchmark with p99, RSS, startup time — not just hot-loop throughput.

Honest numbers

unsafe block count. any count. Test pass rate per file. Coverage diff. Judges will trust a team that says “we got 94% test parity and here's the failing edge case” over a team that claims 100% and can't reproduce it on demand.

You'll submit
  • 01 Public GitHub repo with the port
  • 02 Build command that produces a working binary or runnable artifact in one step
  • 03 The original repo's test suite, hashed at kickoff, passing against your port
  • 04 Differential fuzz harness (we'll provide a template)
  • 05 DECISIONS.md — every non-trivial architectural divergence from the original, with rationale
  • 06 Benchmark report — original vs port, on a shared workload, with methodology
  • 07 5-minute demo video showing the original test suite passing live against your port
05 / Anatomy of a working port

Anatomy of a working port

What a serious submission looks like on disk.

  • 01
    One command builds.

    make, cargo build, or docker compose up. If we have to read your CI to figure out how, you've failed this rule.

  • 02
    Tests are sacrosanct.

    Original suite file-hashes match what we pinned at kickoff. Add tests; don't edit them.

  • 03
    Decisions are documented.

    DECISIONS.md is read by judges and counts toward Engineering Discipline (15%). Empty bullets don't count.

  • 04
    Numbers are honest.

    p99, RSS, startup, throughput — with methodology. Throughput-only benchmarks score below honest p99 regressions.

Layout is advisory. Judges read what you actually ship.
06 / Bonus points

Bonus points

Optional. Pick one. Nail it.

Differential Fuzz Survivor +5 Hard

Run a differential fuzzer (Trail of Bits' DIFFER, or your own) against the original and the port for at least 60 continuous seconds. Zero divergences on a shared public API. Publish the fuzz log.

Zero Unsafe +5 Hard

Land your port with unsafe / any / equivalent-escape-hatch counts under a documented threshold (we'll publish per-pair thresholds at kickoff — calibrated against comparable real-world projects like uv and pingora).

Bug Catcher +3 Medium

Discover and document a latent bug in the original repo through your differential testing. File the issue upstream during the hackathon. Bonus bonus if it gets accepted.

Decision Log +3 Medium

Submit a DECISIONS.md with at least 10 non-trivial architectural divergences and their rationales. Judges will read it. Empty bullet points won't count.

07 / Out of scope

Out of scope

These won't score well. Don't bother.

  • Hello-world translations or single-function rewrites
  • Ports that shell out to the original binary and call it a translation
  • Ports that FFI into the source-language runtime (“we ported it to Rust but link against the Python interpreter”)
  • Editing the original test suite to make it green (this is the Bun mistake — we explicitly score against it)
  • Cherry-picking happy-path tests while ignoring concurrency or error paths
  • LLM dumps with no decision log and no human able to defend the architecture
  • Repos over 8,000 source lines (you will not finish in 72 hours; don't try)
  • Anything requiring custom hardware, GUI frameworks, or proprietary toolchains
We're not against AI-assisted porting. We're against the version of it that ships unsafe-everywhere code, edits the tests, and can't explain its own decisions.
08 / Timeline

Timeline

All times UTC. 2026.

Pre-Event
Jun 29
Registration opens Join the Discord, scout your candidate repo.
Jul 27
Team formation 1–4 people per team. Solo welcome.
Jul 30
Repo candidates posted Pre-vetted pool of ~30 eligible repos (2k–8k LOC, ≥80% test coverage). Pick yours in the first 4 hours of kickoff.
Hackathon — 72h
Jul 31 · 10:00 UTC
Kickoff Original test suites hashed and pinned. Hacking begins.
Aug 03 · 10:00 UTC
Code freeze Submissions due. Test parity verified live.
Post-Event
Aug 03 – 13
Judging window Each project reviewed by multiple judges on structured forms across the one-week window. Weighted scores + written feedback to every team.
Aug 14
Winners announced
Aug 14 – 21
Community voting
Aug 22
Community Choice announced
09 / Scoring

Scoring

How submissions are scored.

Each project is rated on a 5-point scale across four weighted criteria. Final ranking is the weighted average across all judges who evaluated the project.

Criterion Weight What it covers
Functionality & Reliability 40% Does the port build with one command, run, and pass the original test suite unmodified? File-hash verified at submission. A 99% pass rate with zero test edits beats a 100% claim with two suspicious deletions.
Behavioral Equivalence 30% Event-specific. Differential fuzz survival on shared inputs. Property tests survive translation; example-based tests don't. Concurrency semantics under soak. Honest p99 / RSS / startup, with methodology.
Code Quality 20% Idiomatic in the target language to a senior reviewer. unsafe / any / escape-hatch ratio versus comparable real-world projects. Decision-log quality. Error-handling patterns native to the target.
Innovation 10% Creative track-H pair choices that defend themselves. Latent bugs caught in the original via differential testing. Architectural decisions a senior reviewer would adopt upstream.
Bonus challenges
Challenge Difficulty Points
Differential Fuzz Survivor Hard +5
Zero Unsafe Hard +5
Bug Catcher Medium +3
Decision Log Medium +3
10 / Prizes

Prizes

$1,800 total prize pool.

$800

1st Place — Grand Prize

The port that nailed test parity, survived differential fuzzing, reads as idiomatic in the target language, and made the judges say “I'd merge this upstream.”

$400

2nd Place — Runner-Up

Exceptional execution across the board. Strong test parity, defensible architecture, honest benchmarks. Almost took the crown.

$200

3rd Place

A creative translation that stood out for either the surprising language pair or the bug it caught in the original.

$100

Bug Catcher

For the team that discovered and documented the most consequential latent bug in the original repo through their differential testing.

$300

Community Choice

Voted by fellow participants. The port that other engineers want to actually use, fork, or contribute back upstream.

11 / Rules

Rules

What counts as a valid submission.

  • 01
    Pick a Real Repo

    Pick from our pre-vetted pool of ~30 eligible repos (2k–8k LOC, ≥80% test coverage, OSS license) within the first 4 hours of kickoff. Off-pool repos accepted only with judge approval before hour 4.

  • 02
    Test Suite is Sacred

    The original repo's test suite is hashed at kickoff. Any modification to those files at submission = automatic Test Parity score of zero. You can add new tests in your port. You cannot edit the originals.

  • 03
    Standalone & Runnable

    Your port must build with a single command (make, cargo build, docker compose up, etc.) and produce a runnable artifact. No “works on my machine” submissions.

  • 04
    New Code Only

    All port code written during the 72-hour window. Standard library use, open-source dependencies in the target language ecosystem, AI assistance — all fair game. Pre-existing partial ports of your chosen repo are not.

  • 05
    No Source-Language Runtime

    Your Python → Rust port cannot link against the Python interpreter. Your C → Rust port cannot FFI into the original libc-wrapping library. The whole point is to leave the source language behind.

  • 06
    Team Size

    1–4 people. Solo entries welcome. Find teammates on the Hackathon Raptors Discord before or during the event.

  • 07
    Pick a Track

    Choose one track A–H. Your port must clearly target that pair. Open Pair (Track H) requires a defensible rationale in your README.

  • 08
    Source Code Public

    GitHub repo, OSI-approved license. Public at submission. Anonymous-username submissions accepted, but the team must be reachable for written follow-up by judges during the evaluation window.

  • 09
    AI Tools Are Expected

    Claude Code, Cursor, Aider, Copilot, vibe-coding. Use them. We don't gatekeep on whether you used AI; we gatekeep on whether the port holds up. DECISIONS.md, the differential fuzz log, and the original test suite are the receipts. If the artifact can't be defended in writing, it scores accordingly.

12 / Who this is for

Who this is for

If you've ever opened a 10,000-line PR labeled “Rewrite in Rust” and wondered whether anyone actually read it, this is your hackathon.

Backend & Systems Engineers

Tracks · A · B · E

You've spent a year fighting GC tails or memory-corruption bugs. Now pick the migration you've been arguing for in design docs.

SREs & Platform Engineers

Tracks · D · E · F

The reliability story is the migration story. Build the port that proves the p99 case.

Language Implementers & Compiler Folks

Tracks · B · C · G

Cross-language translation is your home turf. Set the bar for what idiomatic looks like.

Open-Source Maintainers

Tracks · A · D · F · H

Pick the project you wish was in a different language and prove the migration is feasible. Upstream the patch if you nail it.

Tooling & DX Engineers

Tracks · C · D · F

The Astral playbook. Take a slow tool, ship a fast one, and report honest numbers.

Polyglot Engineers

Tracks · H

You've shipped in five languages and have opinions. Track H exists for you. Surprise us.

Security Engineers

Tracks · A · B · G

Memory-safety migrations are your beat. Use differential fuzzing to find bugs in the original.

13 / Judging

Judging

Fully online and asynchronous. No live panels, no scheduled calls. Every project reviewed by multiple judges from a curated panel.

  • Format
    Fully online and asynchronous. No live panels, no scheduled calls. Every project reviewed independently by multiple judges drawn from a curated panel.
  • Panel
    Senior engineers, architects, and technical leaders selected to match the event's domain — eight seats, profiles announced Jun 29.
  • Batches
    Projects grouped into batches of ~10–12. Each judge is assigned one batch on a structured online form.
  • Time commitment
    1–2 hours per week over a one-week evaluation window. Comfortable around a full-time role.
  • Criteria
    Four weighted criteria on a 5-point scale, tailored to Port Mortem. See §09 / Scoring for the rubric.
  • Output
    Weighted score per project · written feedback to every team · signed Evaluation Protocol issued to each judge as a permanent record of their participation.
    • Every team receives
    Weighted score · written feedback · judge initials (panel anonymised).
    Panel · 8 seats · announced Jun 29
    • Compiler Engineer
      TBA · Jun 29
    • SRE / Platform Lead
      TBA · Jun 29
    • Language Implementer
      TBA · Jun 29
    • Security Researcher
      TBA · Jun 29
    • OSS Maintainer
      TBA · Jun 29
    • Tooling / DX Engineer
      TBA · Jun 29
    • Differential Testing Specialist
      TBA · Jun 29
    • Cross-language Migration Lead
      TBA · Jun 29

    Know someone? Email hello@raptors.dev with the subject Judge Nomination — Port Mortem.

    14 / FAQ

    FAQ

    What's the team size limit?
    1–4 people. Solo welcome. We recommend 2–3 for the 72-hour window — bigger teams hit coordination overhead fast on a port project.
    Can I use AI code generation?
    Yes, and you should. Claude Code, Cursor, Aider, Copilot — all expected. We don't gatekeep AI use; we gatekeep the artifact. DECISIONS.md, the differential fuzz log, and the original test suite are the receipts. If the port can't be defended in writing, it scores accordingly.
    Can I pick any GitHub repo?
    For tracks A–G: pick from our pre-vetted pool (~30 repos), or get judge approval for an off-pool choice within hour 4 of kickoff. For Track H (Open Pair): any defensible public repo, justified in your README.
    Why the 2k–8k LOC cap?
    72 hours. Real test parity. Differential fuzzing. Honest benchmarks. Anything bigger and you ship a compile, not a port. Bun took 6 days with an agent fleet and merged with 13,000 unsafe blocks — we have less.
    Can I edit the original test suite?
    No. The file hashes are pinned at kickoff. Edited tests = zero Test Parity score. You can add new tests in your port; you cannot modify the originals. This is the explicit lesson from the Bun merge.
    What if the original repo has flaky tests?
    Document the flakes in your DECISIONS.md, exclude them from your parity calculation with a written rationale, and judges will assess case-by-case. Don't silently skip them.
    What counts as “passing the original test suite”?
    The original repo's tests run against your port's binary/artifact via a thin adapter (we'll provide templates for each track). Pass rate = passing tests / total tests. ≥99% with no edits is what scores top marks.
    Can I work on my port before July 31?
    No code. Planning, candidate-repo scouting, agent prompt tuning, reading the source — all fine. Any port code committed before kickoff disqualifies the project.
    What's the differential fuzz session?
    A harness that runs the original and your port on the same inputs and diffs the outputs. We'll provide templates for CLI tools, libraries with HTTP APIs, and parser/serializer projects. Surviving 60+ continuous seconds with zero divergence earns the bonus.
    Can the port be slower than the original?
    Yes, but honest reporting is required. If your port is 2× slower, say so and explain why. Hiding the regression scores worse than disclosing it. Top placements need behavioral equivalence first; performance is a tiebreaker.
    Do I have to use any specific tools?
    No. Use whatever ships your port in 72 hours.
    What if my port discovers a bug in the original?
    File the upstream issue during the hackathon. Document it in your submission. That's the Bug Catcher bonus. The whole point of differential testing is that the rewriter often sees what the original maintainers missed.
    References

    References

    1. [1] BigGo / Theo, “Bun Zig→Rust merge analysis”
      https://finance.biggo.com/news/cdd79ba072c5c5d9
    2. [2] The Register, “Anthropic's Bun Rust rewrite merged at the speed of AI”
      https://www.theregister.com/devops/2026/05/14/anthropics-bun-rust-rewrite-merged-at-speed-of-ai/
    3. [3] Byteiota, “The 13,000 unsafe block problem”
      https://byteiota.com/bun-rust-rewrite-merged-the-13000-unsafe-block-problem/
    4. [4] Techzine, “Bun's Rust rewrite raises questions”
      https://www.techzine.eu/news/devops/141364/
    5. [5] The New Stack, “Microsoft's bold goal: replace 1B lines of C/C++ with Rust”
      https://thenewstack.io/microsofts-bold-goal-replace-1b-lines-of-c-c-with-rust/
    6. [6] IT Pro, “DARPA wants to accelerate C-to-Rust translation with AI (TRACTOR program)”
      https://www.itpro.com/software/development/darpa-wants-to-accelerate-translation-of-c-code-to-rust-and-its-relying-on-ai-to-do-it
    7. [7] Microsoft DevBlogs, “A 10× faster TypeScript (native port to Go)”
      https://devblogs.microsoft.com/typescript/typescript-native-port/
    8. [8] Discord Engineering, “Why Discord is switching from Go to Rust”
      https://discord.com/blog/why-discord-is-switching-from-go-to-rust
    9. [9] Trail of Bits, “Introducing DIFFER”
      https://blog.trailofbits.com/2024/01/31/introducing-differ-a-new-tool-for-testing-and-validating-transformed-programs/
    10. [10] Astral, “uv: an extremely fast Python package and project manager”
      https://github.com/astral-sh/uv
    11. [11] Cloudflare, “Pingora: open-sourcing our Rust framework”
      https://blog.cloudflare.com/pingora-open-source/
    12. [12] Immunant, “c2rust: C to Rust translator”
      https://github.com/immunant/c2rust
    13. [13] arXiv, “SmartC2Rust: LLM-assisted unsafe reduction”
      https://arxiv.org/html/2409.10506
    14. [14] arXiv, “Differential fuzzing for LLM-generated code translations”
      https://arxiv.org/pdf/2602.15761

    Build a port that holds up.

    JUL 31 — AUG 03 · 72H · ONLINE

    Go to the Hackathon Raptors Discord