The graveyard

Not every language on the original roster could be done honestly. These are the ones that could not, each recorded with evidence in INFEASIBLE.md, whose first rule is that nothing on the page is ever deleted. Every one was replaced from the roster reserve list, which is how the roster still reaches one hundred.

Nothing on this page is ever deleted. An entry whose slot has since been filled keeps its row and gains a note naming the replacement. The record of what could not be done, and why, is a deliverable of this project in its own right — not bookkeeping to be tidied away as the roster fills up.

The project's rules require every client to build, test, and verify inside Docker on linux/amd64, with no proprietary licenses baked into images and no GUI-only toolchains. The following roster entries cannot meet that bar. They are recorded here rather than quietly dropped, and each needs a replacement language so the roster still reaches one hundred.

Infeasible — proprietary license, hosted-only, or GUI-only toolchain

Language Why it cannot be done here
apex Executes only inside Salesforce's hosted platform; no local runtime exists. Replaced by Rexx, which is merged and evidenced.
labview Proprietary NI graphical environment; no headless Linux compiler, license required. Replaced by Emacs Lisp, which is merged and evidenced.
matlab Proprietary license required for the real MATLAB runtime; substituting GNU Octave would not honestly be MATLAB.
mql5 Runs only inside the proprietary Windows MetaTrader terminal. Replaced by Hare, which is merged and evidenced.
rpg IBM RPG compilers exist only on IBM i systems; no free Linux toolchain. Replaced by Modula-2, which is merged and evidenced.
sas Proprietary licensed runtime; no free implementation of the real language. Replaced by Icon, which is merged and evidenced.
scratch Block-based GUI language with no network primitives; a Convex client cannot be expressed in Scratch itself. Replaced by SNOBOL4, which is merged and evidenced.
visual-foxpro Discontinued proprietary Windows product; no Linux toolchain. Replaced by Mercury, which is merged and evidenced.
xbasepp Commercial Windows-only Alaska Xbase++ compiler. Replaced by Oberon-07, which is merged and evidenced.
xojo Proprietary licensed IDE-bound compiler. Replaced by ALGOL 60, which is merged and evidenced.
xpp Microsoft Dynamics X++ executes only inside the hosted Dynamics platform.

Infeasible — no way to reach a socket from the language itself

These were assessed in a second sweep. Each was independently challenged by a second reviewer arguing the opposite case; the verdicts below are what survived. A client for any of them would be a bridge — a helper process doing the real work while the language does something incidental — which this project rejects, for the same reason PostScript was declined earlier on this page.

Language Why it cannot be done here
bc Its entire outside world is a numeric stdin and a text stdout. No file handles, no dlopen, no FFI of any kind, so a socket could only ever be an external process.
solidity The EVM has no I/O opcode and Solidity has no extern. A socket would have to be an invented precompile inside a foreign host program.
abap No socket API and no public FFI even on a licensed SAP AS ABAP. The free open-abap route opens its sockets by embedding literal JavaScript inside WRITE '@KERNEL …' string literals, which is JavaScript doing the work, not ABAP.
elm Elm has no socket type and no foreign call — only asynchronous JSON ports. Transport, stdio and the adapter listener would all live in hand-written JavaScript, leaving Elm as a message formatter. This is the PostScript ruling applied consistently.
cfml Lucee, the real open CFML engine, exceeds the 128 MiB container limit and needs to unpack .lco files into a writable temporary directory the read-only runtime cannot provide. BoxLang clears the harness cleanly but is a different language that is merely CFML-compatible — substituting it would be the same move as substituting GNU Octave for MATLAB, already rejected above.
hack HHVM reaches a TCP socket but cannot complete TLS against the real deployment, and there is no escape hatch. Its only in-language TLS mechanism, the PHP-derived stream_socket_client('ssl://…') / stream_socket_enable_crypto() API, fails the handshake against the hosted backend under five distinct context configurations (default, explicit SNI/crypto_method, verification disabled, explicit modern ciphers, TLS1.2-only ciphers), always with ssl3_read_bytes:sslv3 alert handshake failure; the same container's raw openssl s_client succeeds (TLS 1.3, ECDSA certificate), and forcing it to RSA-only ciphers reproduces the identical alert — HHVM's wrapper never offers an ECDSA-compatible ClientHello and its context options cannot override that. HHVM ships no FFI extension, so the raw-socket-plus-OpenSSL route is closed. Two further findings compound it: both public distribution channels (Docker Hub hhvm/hhvm and the dl.hhvm.com apt repo) stopped publishing in March 2023 — the newest image carries EOL Ubuntu 20.04 and EOL OpenSSL 1.1.1f with no maintained install path — and the Hack compiler is not separable from the runtime: there is no standalone hackc; the one hhvm binary any runtime image must ship still exposes the general-purpose --hphp compiler mode even in a trimmed image, which fails the no-compiler runtime rule and cannot be stripped without an upstream rebuild. Probe evidence on branch codex/hack-feasibility under hack/feasibility/. Replaced by Icarus Verilog.
futhark The toolchain itself is fine — futhark is a free, single Debian package (apt install futhark) that installs unattended and compiles in seconds. The language is the problem: Futhark has no I/O primitives at all, by design. futhark c --library emits only a numeric marshaling C API (futhark_context, entry points over arrays, tuples and opaque records via futhark_new_opaque_*/futhark_project_opaque_*); the non-library futhark c mode's standalone executable is entirely a compiler-generated CLI for Futhark's own benchmarking data format (--runs, --entry-point, -b/--binary-output) with no flag, hook, or extension point that touches a file descriptor, let alone a socket. There is no extern, no FFI directive, nothing a .fut source file can write to request one. The only honest structure is a C host program that owns every socket, TLS handshake and WebSocket frame while calling into Futhark for something incidental — a bridge, not a native client, exactly the shape this project has already declined for PostScript, bc and elm above.

Infeasible — no reproducible, non-interactive build reachable

Unlike the table above, this entry's language genuinely reaches a real socket from its own source, natively. It is recorded separately because that is not where it fails: it fails this project's Docker-only, hermetic-build rule, in a way none of the other entries on this page do.

Language Why it cannot be done here
unison The socket and TLS claim was fully proven, not just documented. Running non-interactively inside a bare debian:trixie-slim container on linux/amd64 via ucm run.file (piped stdin, zero prompts; ucm --codebase-create boots headless), the expression Connection.tls (HostName "example.com") (Port "443") opened a real TCP connection, completed a certificate-verified TLS handshake against a public host, sent a plaintext HTTP GET over it, and printed back a genuine decrypted HTTP/1.1 200 OK response — a full round trip, on ucm release/1.3.0 (built 2026-05-13). IO.net.Socket and the functions underneath Connection.tls are confirmed builtin (e.g. builtin lib.unison_base_7_19_2.IO.net.Socket.client.impl), i.e. real runtime primitives, not a foreign-process shim. What kills the entry is reproducibility, not capability: Socket, Connection.tls, and every ergonomic helper this used — even HostName, Port, and Text.toUtf8 — live in the base library, and the only route to base in the current toolchain is lib.install/pull against @unison/base/releases/... on Unison Share (confirmed: help pull and help lib.install in ucm 1.3.0 document only that Share project syntax). The historical git-remote pull syntax (pull https://github.com/user/repo:branch .path) has been removed from the parser — attempting it now is a parse error. The unisonweb/base GitHub mirror is explicitly marked deprecated by Unison Computing itself ("Unison code hosting for this library has migrated to Unison Share"), so it is not a usable offline substitute either. The raw compiler builtins underneath base's wrappers are real, but they are addressable only by content hash, not by name, and there is no local or offline way to discover those hashes without first consulting a codebase that has already resolved names through a Share pull; a guessed bare reference to one (##IO.socketSend.impl) was rejected by the REPL as unknown, confirming FFI-level builtins carry no special parser syntax the way ability types like ##IO do. Every Dockerfile path to a working client therefore needs a docker build-time (or, if deferred, a container-start-time) network round trip to one hosted third-party service outside this project's control — exactly the "network access to Unison Share at build time" failure this candidate was explicitly held to before acceptance. Futhark's vacated slot (slot 3, replacing matlab) is therefore still open.

Infeasible — toolchain rejected by this project's container security posture

This candidate reaches neither the socket gate nor the toolchain gate cleanly: its own bootstrap binary cannot run at all under this project's Docker constraints, at build time or run time, for a reason that has nothing to do with the language.

Language Why it cannot be done here
pop11 Poplog (the toolchain behind Pop-11, held in reserve for this slot pending Seed7) bootstraps every further build stage from a "corepop" binary — a fixed-address heap image inherited from a 1980s VM design — that calls personality(ADDR_NO_RANDOMIZE) before it can load. Docker's default seccomp profile rejects that specific flag value; this project's ./run script never passes a custom --security-opt seccomp=, so both docker build (BuildKit's own RUN sandbox) and every docker run this project performs use that same restrictive default. The result under it is not a permission error but a crash — MEMORY ACCESS VIOLATION — reproduced directly against all five corepop images GetPoplog ships (010 through 050, spanning 2012–2021 builds); --security-opt seccomp=unconfined makes the identical binary succeed immediately, and that flag is unavailable both inside this project's hermetic build and inside the read-only, capability-dropped runtime container the shared verifier launches. GetPoplog's own repository ships a bespoke docker/poplog_seccomp.json profile and a "Running poplog under Docker" wiki page for exactly this reason — a documented, upstream-acknowledged constraint of the toolchain under containers, not a one-off flake or a fixable Dockerfile mistake.

Infeasible — the runtime's own footprint exceeds the container limit

The only entry on this page ruled out on resource footprint rather than capability. Both the language and the client are sound: a complete hand-rolled client exists and passes its language-local suites, including five reconnect cycles. It is the interpreter that does not fit.

Language Why it cannot be done here
raku Every runtime container in this project is limited to 128 MiB, uniformly across all hundred languages. Three removable layers were stripped in turn and measured by cgroup bisection under docker run --memory N --memory-swap N, five trials per side. Cro: replacing Cro::HTTP::Client/Cro::WebSocket with hand-rolled HTTP/1.1 and RFC 6455 over IO::Socket::INET cut the total from 190–210 MiB to 170–185 MiB — a real 20–25 MiB, and the client still worked. Rakudo Star: a bare Rakudo 2026.07 built from source, compiler and VM only, has a floor of 106 MiB for raku -e 'say 1' versus 134–140 MiB for the Star bundle, confirming that most of the original cost was the bundled modules rather than the interpreter. Every external module: binding libssl and libcrypto directly through NativeCall, which is core to Rakudo and needs no distribution, and hand-rolling JSON, base64, SHA-1 and randomness, was measured against a real TLS handshake and HTTP round trip to the hosted deployment — 145–170 MiB with zero Convex code loaded. That last figure also corrected an earlier, flattering 140 MiB reading taken from a probe that loaded the TLS module but never opened a connection. MoarVM offers no nursery or heap-size environment variable (MVM_NURSERY_SIZE is a compile-time #define), and its one memory-relevant tunable, MVM_SPESH_DISABLE, is worth about 15 MiB and was already shown to make the real WebSocket workload too slow to complete. After removing every removable layer the floor is still 17–42 MiB over budget before a single line of client code runs. The hand-rolled transport work is preserved on branch fix/raku-rp2 should the limit or the runtime ever change.

Infeasible — license or GUI gate (ruled, previously borderline)

Michael's ruling: entries requiring a proprietary license or a GUI toolchain are not built. Recorded here rather than left open.

Language Why it cannot be done here
wolfram-language The free Wolfram Engine requires Wolfram-ID activation or a metered cloud entitlement, forbids redistribution inside images, and wants a writable password file plus live egress on every kernel start.
q Technically excellent — kdb+ has had a built-in WebSocket client since 2014 — but every route to the binary needs a KX account, an OAuth2 bearer token and a per-user kc.lic license file.
gml GameMaker refuses to emit a binary without an interactive IDE sign-in, its Linux export is an OpenGL/X11 game runner rather than a headless program, and external_define has no Linux shared-object path.

Infeasible — reaches a real socket, but TLS is walled off by the toolchain's own tooling

Unlike every entry above, this one is not a language-design or licensing wall. Two of its three gates passed outright, with committed, reproducible evidence.

Language Why it cannot be done here
oz Open.socket is a genuine Mozart 2 built-in and completed a real HTTP round trip to a live host from inside a from-source Docker build (five modern-toolchain incompatibilities in the 2016-era build system found and fixed along the way — dead git submodule protocols, GCC 12 header changes, obsolete Boost/JVM flags, a Scala 2.10.4 bootstrap needing a fetched Temurin 8). TLS is the wall: oztool, the "DLL Builder" the language's own documentation describes for exactly this, is a Mozart 1.x tool that does not exist anywhere in Mozart 2 — verified by direct grep of the full v2.0.1 source tree. The real extension path is VM-source-level: add a native builtin and rebuild the VM proper. That was attempted honestly. A TLSConnection class over boost::asio::ssl::stream (certificate chain and hostname verification both on) was written and wired into ModOS as four new builtins, needing five further fixes to Mozart 2's own unmaintained 2016 AST-dump code generator to even compile against Debian's only available Clang (an 8-major-version gap). The generator then compiled and linked, and clang++ produced a valid AST file — but generator intfimpl <ast> <outdir> crashed on the specific header that carries the new builtins (boostenv.hh), always at the identical point: exactly 90 output files, always stopping at the Chunk declaration. Because one earlier, unrelated run against a different header had completed cleanly, a bounded retry loop was tried on the theory the crash was one-shot and address-layout-sensitive rather than deterministic — 200 attempts through the project's real make genboostsources target, plus 8 further manual attempts under gdb and varied stack limits: 208 consecutive failures, zero variation, same file every time. That fixed point is a genuine, reproducible memory-safety defect in Mozart 2's own ~1000-line, long-unmaintained AST-walking tool, not bad luck. setarch -R to disable ASLR was correctly not attempted — Docker's default seccomp rejects personality(ADDR_NO_RANDOMIZE), the identical mechanism that already ruled out Pop-11 above. Replaced by Modula-3, which reaches TLS through its own long-stable, actively-interoperable C FFI rather than through 2016-era vendored LLVM tooling.

At risk, not yet abandoned

Language State
actionscript Nine real defects fixed; blocked on Apache Royale's Closure Compiler pass renaming JSON object keys on the wire, which rewrites the protocol itself. The fix is mechanical — bracket notation at every dynamic access — but spans an unknown number of call sites.
logo Lhogho's libload/external is a genuine dlopen FFI, and socket()/connect() were driven successfully from Logo source. But it is 2012-era i386 abandonware, and this project has already learned what emulated architectures do to trust in a result.

Chosen replacements

Eleven entries are infeasible, so eleven replacements are needed to keep the roster at one hundred. These were selected against four criteria: a free toolchain that installs unattended in Docker, enough of a standard library or C FFI to reach a socket and speak TLS, a genuine claim on a viewer's interest, and variety across eras and paradigms rather than eleven more curly-brace languages.

# Replaces Language Toolchain Why it earns a slot
1 apex Rexx Regina Rexx The scripting language of mainframes, OS/2 and Amiga. Ubiquitous for two decades, near-invisible today.
2 labview Emacs Lisp Emacs batch mode A Convex client inside a text editor's extension language. Emacs has real network primitives and TLS, so this is honest, not a stunt.
3 matlab Futhark → see below — Futhark itself turned out infeasible once actually tried; see the "no way to reach a socket" table above and the note below the table.
4 mql5 Hare hare A deliberately small systems language, self-hosted, no runtime. Modern, obscure, and a fair test of doing everything by hand.
5 rpg Modula-2 GNU gm2 Wirth's successor to Pascal, and a GCC front end, so it builds anywhere GCC does. Direct historical line from the Pascal family already on the roster.
6 sas Icon Unicon Griswold's goal-directed evaluation with backtracking built into the language. Unlike anything else here.
7 scratch SNOBOL4 CSNOBOL4 1962, and still the most distinctive pattern-matching model ever shipped. The oldest language in the project.
8 visual-foxpro Mercury mercury Logic programming with strong static types and a real module system — Prolog's ideas taken seriously.
9 xbasepp Oberon-07 OBNC Wirth's final, radically minimal language. A whole client in a language whose report fits in sixteen pages.
10 xojo ALGOL 60 GNU MARST 1960, and the ancestor of nearly everything else on this roster: block structure, lexical scope, recursion and BNF all arrive here. The oldest language the project adds, and older than every entry except Fortran, Lisp and COBOL, which it predates in influence if not in date.
11 xpp ATS ats2 Dependent types over C, proving memory safety at compile time. The most demanding type system in the project.

Deliberately not chosen, and why:

If any chosen language proves infeasible once its toolchain is actually pinned in Docker, it moves to the table above with its reason recorded, and the next candidate takes the slot.

Futhark (slot 3, replacing matlab) is the first case of this: confirmed infeasible after actually pinning the toolchain and reading the generated C API, moved to the "no way to reach a socket" table above. Hare (slot 4, replacing mql5), tried in the same session, succeeded and is evidenced separately.

Unison (the content-addressed functional language from Unison Computing, not the unrelated Benjamin Pierce file-synchronization tool of the same name) was tried for Futhark's now-open slot and, unlike Futhark, cleared the socket-and-TLS proof cleanly — see the "no reproducible, non-interactive build reachable" table above for the demonstrated TCP+TLS round trip. It is ruled infeasible anyway, on a different axis: the language's entire standard library, including the ergonomic Socket/Tls API that proof used, ships only through Unison Share, and the current ucm (release/1.3.0) has removed the old git-remote pull path that used to make that optional. There is no way to reach a hermetic, non-interactive Dockerfile build for it. Slot 3 (matlab → Futhark → Unison) is still open and needs a further candidate.

Second replacement round

The sweep above ruled out eight more entries, so eight more replacements are needed. The same four criteria apply: a free toolchain that installs unattended in Docker, a genuine socket and TLS route the language's own code drives, a real claim on a viewer's interest, and variety across eras and paradigms. Slot mapping is cosmetic — the slots are fungible.

# Replaces Language Toolchain Why it earns a slot
12 q APL (1966) GNU APL The glyph language itself rather than a descendant. ⎕FIO exposes socket, connect, send and recv, with user-compiled native functions as the sanctioned OpenSSL path. Recovers the array-language slot the KX signup form took.
13 abap MUMPS / M (1966) YottaDB Opens its own TCP with no FFI at all — OPEN d:(CONNECT="host:port:TCP") — and negotiates TLS through a bundled OpenSSL plugin. Still runs a large share of the world's hospital records, which is the enterprise-invisibility story ABAP was going to tell.
14 bc Simula 67 (1967) GNU Cim Classes, objects, inheritance, virtual methods and coroutines were all invented here. Cim compiles to C and supports external C procedure, the same build shape as the ALGOL 60 entry that already succeeded.
15 solidity VHDL (1983) GHDL, VHPIDIRECT A hardware description language, DoD-commissioned like Ada, that GHDL compiles to a standalone native executable. The strangest honest entry available, and the mirror image of Solidity's failure: the wrong kind of machine that turns out to have a door.
16 gml Oz (1995) Modula-3 — see the Oz entry below; Oz proved infeasible on its own transport, not on any defect of GameMaker's.
17 wolfram-language SETL (1969) GNU SETL Sets and tuples as the primitive data types, and the language NYU used to prototype the first Ada compiler — the mathematically-founded slot Wolfram was going to fill, at a fifth of the age.
18 elm Dylan (1992) Open Dylan Apple's Lisp-with-syntax, built for the Newton and then killed. Multimethod dispatch and a real macro system behind ALGOL-ish syntax, with define C-function for the transport boundary. A functional slot that is genuinely dead rather than merely unfashionable.
19 cfml Harbour (xBase, 1985 lineage) Harbour Restores the xBase family the project lost twice, to visual-foxpro and xbasepp, honestly and for free. The language behind a decade of DOS business software, compiling straight to C so the socket and TLS boundary is routine.

Slot 3 (originally matlab) has now defeated two candidates: Futhark, which cannot reach a socket at all, and Unison, which reaches one perfectly but cannot be built without a network round trip to a hosted third-party service. The third candidate is chosen against both failures at once:

Pop-11 (Poplog), held in reserve for this slot, was tried once Seed7's own gates cleared and turned out infeasible for a reason specific to this project's container security posture rather than the language; see the new "toolchain rejected by this project's container security posture" table above for the evidence.

Raku's slot, vacated on footprint rather than capability, is filled by:

Considered in this round and not chosen:

Hack's slot, vacated on a TLS stack that cannot be reached around, is filled by: