What if there was no BASIC in EndBASIC?
An overview of the cool technical building blocks behind EndBASIC and what they could turn into if they evolved on their own
Six years have passed since I started building EndBASIC: a retro-looking BASIC interpreter that works on the web, on the desktop, and on embedded hardware—and that allows writing cross-platform apps that leverage graphics, a cloud file sharing system, and even access to local hardware via GPIO.
But as cool as this sounds, and as exciting as the journey has been, there is something that keeps bugging me about the future of the project: who wants to invest time building something new on an abandoned language? Even Visual Basic, a real platform that evolved over many years and gained “serious language features”, has fallen out of fashion and is, as far as I know, in “maintenance mode” by Microsoft.
So I’ve been thinking… “What if there was no BASIC in EndBASIC?” Or, in other words, how could I leverage the many pieces I’ve created underneath this project to build something that people actually want to use, be it for retro-style development or for other purposes?
In fact, the BASIC portion of the whole project—that is, the language parser and compiler—is the least interesting one. Yes, I’ve written a BASIC interpreter, but the amount of features my dialect provides today is… limited, and building those up is not the most exciting thing to do. For example: records and files are very much needed features, but adding them is not going to make the project much cooler or useful than it already is.
So: let’s look at the building blocks (BBs) behind EndBASIC so that we can imagine how these pieces could be recombined to form something different.
BB1: A pure compiler and VM
At the root of EndBASIC lives a “pure” language core with a relatively simple, non-optimizing (yet) compiler and accompanying VM that can be extended via native Rust bindings and that can be embedded into Rust programs. It’s trivial to leverage this core language to implement imperative DSLs or even dynamic configuration files.
What does “pure” mean here, though? Simply put that the core language, implemented as a separate crate with minimal dependencies, has absolutely no function nor command definitions in it. The programs executed by this VM can have no side-effects nor escape the VM by default: all they can do is compute values, maybe based on global variables injected by the host.
Consumers of this core crate, like EndBASIC’s standard library, are responsible for implementing all functions and commands that make the language useful—but these are all intentionally kept out of the core. Even fundamental primitives that you would expect a BASIC dialect to provide, like PRINT or INPUT, are not part of the core language. This poses some difficulties in the implementation of the compiler but they are an explicit design choice to keep the core lean.
BB2: A portable console framework
Underneath EndBASIC’s graphics drawing commands, there is a collection of Rust primitives to interact with a possibly-graphical console.
Today, this console runs on various environments, including:
The text-based Windows and Unix-like terminals via the
crosstermlibrary.The SDL library for native desktop graphics support across Windows and Unix-like systems (including macOS and Linux, of course).
The HTML5 canvas to target the web browser.
The NetBSD wscons framebuffer to target “boot-to-EndBASIC” environments.
The ST7735s LCD (but more generally, SPI-based LCDs).
For all graphical backends, these Rust primitives provide consistent basic rasterization algorithms for common shapes and support different bitmap fonts.
BB3: An abstract virtual file system
Behind EndBASIC’s file operations lives a Rust library that implements a virtual drive-based file system with multiple implementations for these drives. Right now, drives can be backed by:
Memory, like a ram disk.
A collection of read-only files hardcoded into the binary.
A single directory in the host’s file system.
The browser’s local storage.
A cloud service.
The cloud service drive is backed by the EndBASIC Service, which provides a simple REST API for file access and mutation. Files stored in this drive can be user-private, but they can also be shared with specific users or be made public.
BB4: An embedded disk image builder
Powering the EndBOX, we have a NetBSD base system slimmed down to a minimum set of components with the ability to boot into a graphical application within seconds of powering up the device.
The system image has been designed so that it’s possible to access configuration files and user data from Windows and macOS hosts with ease, allowing tuning the system and performing backups without having to access the inner NetBSD OS. In other words: NetBSD is just an implementation detail that is invisible to users of this image.
This platform is accompanied by a custom collection of robust build scripts that coordinate compiling NetBSD from scratch with the cross-building of a Rust application that uses the console framework described earlier. These scripts then take care of bundling the cross-built binary into the image and starting it up early in the boot process. You can think of this as a simple version of buildroot but NetBSD-based and explicitly targeted at creating application-specific images for embedded devices.
What’s more: in order to support the needs of an application that starts so early in the boot process and to ensure the application can run with the least amount of privileges, the platform provides an RPC mechanism and a privileged daemon that can be used to escalate privileges for specific operations (such as rebooting the machine). And there is also a daemon to optionally collect completely anonymous telemetry (things like version numbers, host architecture, and graphics device in use) from deployed devices.
So, what could we do with these?
As you were reading through the four building blocks above, I suspect some ideas might have come to mind about what could be done with these pieces without necessarily keeping the BASIC dialect around.
Here are some of mine for how this project could evolve:
Continue building the BASIC language up. Yes, of course that’s a possibility! EndBASIC itself is a fun project to work on, and adding more features to it and continuing to build up this retro environment is a never-ending source of joy. Even if I question the point later…
Replace BASIC with a real language. As I said earlier, further developing the BASIC dialect is not super interesting, particularly because BASIC is full of warts that make it hard to parse. So what if you got the exact same retro, cross-platform experience that EndBASIC currently offers but based on a real language that people like using these days? Lua is a strong contender… but so could be LISP or Scheme. I don’t know much about the latter two, but knowing that LISP machines used to exist… they could be pretty fitting.
Focus on the core. I kinda like the idea of having a pure compiler and VM that can be extended to form DSLs, all written in Rust. So maybe building on this specifically is another possible path? The problem is that there already are more languages in the world than you can imagine, so pursuing this feels like a dead end right from the beginning, and I’m not even sure what it’d mean.
A BSD-based buildroot alternative. buildroot works, but it’s based on Linux and comes with the problems that you’d expect from Linux: you are essentially assembling a disparate set of components built by different people with little communication. Putting them together gives you “something”, but it is not cohesive. The platform behind EndBASIC, however, carries an opinionated design for how embedded disk images should be, and provides basic services to enforce security principles, to preserve privacy, and to be performant. So what if you could write a Rust-native program that leveraged my console and file system abstraction primitives, and could deploy it to an embedded device with ease as “a full OS”?
Something something AI. There is no denying that AI is here to stay, so I’ve also been wondering how it might be related to EndBASIC. AI coding agents are great for prototyping ideas, and EndBASIC is a great platform to showcase flashy results with very little code. So maybe EndBASIC could become a good target for coding agents so that you could vibecode embedded projects?
Next steps
I wrote this article sometime last year after running out of steam: shipping the EndBOX was a lot of work and, once that was out, I had to take a break. Honestly, it was a bit disappointing to receive so little interest. By Christmas, I picked up the draft and was almost about to publish it. But then…
In January, I started working on a full re-implementation of EndBASIC’s core language, because reasons that are not important now. This means that the “next steps” have been decided already, at least for the next few months: this rewrite is landing imminently as I mentioned in the EndBASIC 0.12 release announcement from last week. Once that happens, I’ll want to spend some time building up some features that I’ve been wishing to have but never got to for years. In particular, I want to provide some extra graphics manipulation primitives (primarily for sprites) and I want to finally add sound support.
But all other ideas are still on the table, and I’m curious: do any of them pique your curiosity?
i feel the urge to implement a lisp… huh. did i order an endbox? must look.
Yours is an extremely cool project, so I’m sorry if the lack of response (temporarily) discouraged you. I’m very impressed by your progress and persistence and there are many parts I would love to play with, except for the lack of time.
As far as potential “other” languages go, I’d agree with Balthasar on Scheme: there are many and little interest in all of them. But if you want to just plug it in, as opposed to building another language implementation from scratch yourself, it’s a natural choice along Lua. It depends whether you want to demonstrate the language pluggability, vs spend time building your own.
I am partial to Python, although ofc it’s grown enormous. But if you look at v1 from the mid-90s, it started of very simple. And v2 was in a pretty sweet spot of feature, too. But it would probably be harder to distinguish yourself from MicroPython.
If you want something really retro and eye-catching, I’d recommend Logo. Or maybe Smalltalk-80, but language as pure-OO, not the whole environment and VM “os”.