Foxscript targets aging Visual FoxPro apps with a Rust-based runtime

Foxscript is offering a new runtime for the Visual FoxPro language, aiming to keep aging business applications useful without requiring a wholesale rewrite. The project, featured on Hacker News, describes a Rust implementation compiled to WebAssembly and checked against Microsoft’s Visual FoxPro 9 executable.

The pitch addresses a stubborn problem in business software: an old application can remain essential long after its underlying technology stops advancing. Replacing it means more than translating code. The project’s description frames the potential disruption to a working business as the central reason to preserve the existing language rather than start over.

According to the source material shared on Hacker News, Foxscript grew out of a customer’s desire to continue using an existing application for the foreseeable future. That makes continuity—not simply a new set of language features—the project’s defining proposition.

Keeping old code useful

The project’s account places Visual FoxPro’s endpoint at version 9 in 2007 and describes applications still operating within its 32-bit environment. Foxscript proposes a different runtime underneath that familiar language, while retaining some of the surrounding infrastructure those applications may depend on.

Among its stated capabilities are tables beyond the old 2 GB limit and continued loading of legacy 32-bit `.fll` add-ins. Those are consequential compatibility claims: preserving source code alone would not necessarily preserve an application’s usefulness if its data or extensions could no longer work alongside it.

Foxscript also adds lambdas, JSON support and an HTTP server. Together, those additions suggest a route to extending existing software rather than merely keeping it frozen. JSON and HTTP support, in particular, offer building blocks for exchanging data and exposing functionality without making a complete replacement the starting point.

The supplied description does not explain how every feature works or establish compatibility across existing Visual FoxPro applications. Its statement that the runtime is checked against `vfp9.exe` identifies a reference for testing, but it is not, on its own, evidence that every application will behave identically.

Compatibility is the test ahead

There are explicit gaps. Reports are not finished, and the available builds are unsigned. For an application that depends on report generation, the first limitation could be decisive. Unsigned builds are also a distribution consideration that prospective users will need to assess before adoption.

The project is released under the MIT license, making its code available on permissive terms. That does not settle questions about operational readiness, but it gives interested developers a basis for examining the implementation rather than relying solely on the project’s claims.

What matters next is how well Foxscript handles the particular code, tables, extensions and reports that make an existing application valuable. Its proposition is compelling precisely because it avoids treating a rewrite as inevitable. Whether it can deliver that continuity will depend on compatibility in practice—and on closing the unfinished pieces it already acknowledges.