Doom Runs in 518 MB of Brainfuck
This week's esolang GitHub scan (May 7–14, 2026) surfaces three picks from 14 confirmed repos: BFDoom — a playable Doom port compiled to 518 MB of raw Brainfuck; stark — a REST API framework for Dyalog APL; and a near-complete Funge-98 interpreter built in five days.
GitHub, May 7–14, 2026: 14 new repositories across Brainfuck, Malbolge, Whitespace, APL, and Befunge. One is a genuine milestone in deliberate absurdity. One is quietly solving a real problem in a language that has no business solving real problems. One is a spec-faithful engineering exercise in a language most people have never heard of.
Most absurd. Most practical. Most show-off.
Most absurd: Doom in 518 MB of Brainfuck
Doom has been ported to calculators, oscilloscopes, pregnancy tests, and ATM screens. The logical next step, apparently, was Brainfuck.
On May 10, GitHub user jasperdevs published BFDoom: a playable port of the 1993 shooter compiled entirely to Brainfuck — the esoteric language (esolang) that reduces all computation to eight symbols (
>, <, +, -, ., ,, [, ]) operating on a tape of memory cells. 1The main source file,
programs/bfdoom-linked.bf, is 518,406,616 bytes — a little over 518 MB — of nothing but those eight characters. 2 Only the gzip-compressed version is committed to the repo; the uncompressed file is too large for standard Git workflows.How it works
The pipeline runs through ELVM (Esoteric Language Virtual Machine) — an open-source toolchain that compiles C to a portable IR format, which can then be transpiled to a target esolang. The chain here: Doom C source → ELVM IR (918,947 IR instructions) → Brainfuck. 2
One problem: ELVM's standard Brainfuck backend uses a 16-bit program counter, which tops out at 65,535 addressable instructions. A Doom-sized linked IR blows past that instantly. The project's solution involved a cached-optimized Brainfuck program, a VM snapshot taken after Doom's initialization phase, and a host shortcut for keyboard input. The host process handles three things: executing BF instructions, feeding in WAD asset bytes, and passing keyboard events. Everything else — all of Doom's logic, AI, physics, and rendering — lives inside the Brainfuck code. 2

Image from jasperdevs/BFDoom
What's actually playable
Movement (WASD/arrow keys), turning, firing, weapon switching (keys 1–7), the automap (Tab), and the menu screen (Esc) all work. 1 Sound and full engine parity are listed as unfinished. Per the README: "BFDoom is playable and still being brought closer to Doom. The biggest unfinished pieces are sound, menus, and full engine/rendering parity." 1
You can run it right now:
npm install -g @jasperdevs/bfdoom
bfdoomOr without installing:
npx @jasperdevs/bfdoom. Node.js 20+ required. Windows users need WSL.![Terminal screenshot showing a slice of the generated Brainfuck source: dense rows of +, -, >, <, [, ], . symbols](https://storage.neodrop.ai/grains/media/YmfZdkJ7uoJSDKMwYe0lD.png)
Image from jasperdevs/BFDoom
Why this matters
BFDoom is not the first time someone has compiled C to Brainfuck — that's been a party trick for years. What's new here is the scale: a complete, interactive game with real-time rendering and user input, running end-to-end through BF. The project earned 15 stars in its first week and attracted coverage from Russian gaming outlet Playground.ru, whose writers noted the level of AI assistance involved in the compilation process. 3 The original Reddit posts (r/brainfuck and r/coolgithubprojects) were deleted before they could be archived, so community vote counts aren't available.
The GPL-2.0 license means the full 518 MB of hand-generated chaos is yours to study, fork, and extend.
Most practical: a REST API framework for Dyalog APL

APL (A Programming Language) is a language from the 1960s built around array operations and a symbol set dense enough that its source code is often illegible to anyone who hasn't memorized a specialized keyboard layout. It looks like this:
⍺←⍵[⍋⍵]. It can sort an array in a single character expression. It is not, historically, the language you'd pick to build a web API.On May 14, GitHub user Bombardier-C-Kram published stark: a Fastify-style HTTP routing layer for Dyalog APL (version 20.0+, a commercial APL interpreter), built on top of Jarvis — Dyalog's existing HTTP server package. 4
The core idea: instead of manually parsing request paths in Jarvis's REST mode (which becomes unmanageable as an API grows), Stark lets you declare routes directly:
stark.Get '/users/{id}' handler_fn
stark.Post '/orders' create_order_fnPath parameters are extracted automatically. The framework handles GET, POST, PUT, DELETE, and PATCH. 4
The OpenAPI angle
The feature that bumps this from "neat toy" to "could be useful": Stark auto-generates an OpenAPI 3.0.3 spec at
/openapi.json. As the README puts it, "This opens the door to Swagger UI, auto-generated client libraries (including APL clients), Postman collections, LLM tool integration, and any other tooling that consumes OpenAPI specs." 4There's one delightful APL-specific quirk: APL identifiers can't contain
/, so content-type keys like application/json are mangled to ⍙application⍙47⍙json — the slash replaced with its ASCII code sandwiched between APL's ⍙ character. 4 It's a very APL solution to a very APL problem.At 64 commits and MIT-licensed, this isn't a proof-of-concept sketch. The author's own note: "Not yet ready for production use. Feedback is welcome — please open a GitHub issue if you have thoughts or run into problems." 4 That's a reasonable place to be for a first public release of a web framework in an array language.
Most show-off: implementing the full Funge-98 spec in a week

Befunge is an esoteric language from 1993 where the program is a 2D grid and execution can move in any of four directions — left, right, up, down. The instruction pointer bounces around the grid, executing whatever character it lands on. Befunge-98 (also called Funge-98) is the generalized extension of that idea: N-dimensional, with a fully specified standard for how N-dimensional "Funge" programs should behave. One-dimensional Funge is Unefunge. Two-dimensional is Befunge-98. Three-dimensional is Trefunge. The spec runs to dozens of pages.
On May 10, GitHub user ItsSkyWasTaken started Funge98-Interpreter: a C++ implementation of the Funge-98 specification, built from scratch. 5
By May 14 — five days later — the commit log read: "Add all but five of the standard commands." 5 Eight commits total: initial scaffold, then Stack, then InstructionPointer, then components, then the bulk of standard commands in two passes.
The implementation covers the core infrastructure a Funge-98 interpreter requires:
- Stack: per-IP stack with standard push/pop/clear operations
- InstructionPointer: direction state, delta vector, storage offset, and wrapping
- World: the Funge-space grid, addressable by position
Funge-98 is not a trivial target. The spec includes thread-like concurrent execution (multiple instruction pointers), fingerprint (extension) loading, and multi-dimensional wrapping semantics. Getting all but five standard commands working in a week of side-project commits is the kind of thing that reads as "I just wanted to see if I could." 5
Zero stars so far. Zero forks. But it exists, it compiles, and it's apparently nearly complete.
The rest of the week
No Whitespace repositories appeared in the May 7–14 window. The word "whitespace" overlaps too heavily with non-esolang content to surface cleanly in GitHub search, and no new Whitespace-language projects were found across keyword-based searches either.
The APL family also produced jsogarro/datasets, an 8,000-example QLoRA fine-tuning corpus for a Q/kdb+ specialized AI coding assistant, with a 100-task benchmark scored via an actual Q interpreter. 6 Not an esolang project in the traditional sense — but if you're building LLM tooling for financial time-series code, the dataset structure is concrete enough to dissect.
Cover image from jasperdevs/BFDoom
このコンテンツについて、さらに観点や背景を補足しましょう。