Decoupling Targets from the Compiler
As AiLang progresses through the 0.0.1 Release Candidate series, the focus is shifting.
Most of the major language features are in place. The virtual machine is stabilizing. The standard library continues to grow.
Now the work is increasingly about refining the architecture before the first stable release.
One of the most significant architectural milestones we've recently completed is the separation of Targets from the compiler.
It may not be as flashy as a new language feature, but it fundamentally changes how the entire ecosystem will evolve.
The Problem
Originally, platform support lived alongside the compiler.
That approach works well early in a project's life, but it doesn't scale.
Every new platform adds more complexity.
Every platform-specific bug potentially requires releasing the compiler.
Every experimental platform increases the maintenance burden for everyone—even developers who will never use it.
As we started planning support for additional targets, the architecture no longer felt right.
Questions started coming up like:
- How do we support Raspberry Pi?
- What about BeagleBone?
- Embedded ARM boards?
- Headless cloud services?
- Mobile platforms?
- An operating system?
The compiler shouldn't need to know about any of those.
Its job is to understand AiLang.
Nothing more.
A New Separation of Responsibilities
The solution is surprisingly simple.
Instead of shipping every platform inside the compiler, Targets become installable packages.
The compiler understands the language.
Targets understand platforms.
AiLang Compiler
│
┌──────────┴──────────┐
│ │
AiVM Runtime Package Manager
│
┌──────────────────────────┼──────────────────────────┐
│ │ │
target-linux target-macos target-windows
│ │ │
target-wasm target-aios target-rpi
│ │ │
...and any future targets...
This gives every target its own lifecycle.
Need to update Raspberry Pi support?
Release a new Raspberry Pi target.
Need support for a new Apple SDK?
Update the macOS target.
Want to experiment with an entirely new platform?
Build a new target package.
The compiler doesn't change.
Why This Matters
This architecture has several advantages.
Independent Releases
Platform support no longer dictates compiler releases.
Each target can evolve independently.
Smaller Core
The compiler remains focused solely on understanding the language.
That keeps it easier to maintain, easier to test, and easier to reason about.
Cleaner CI/CD
Each target can have its own build pipeline, tests, dependencies, and release cadence.
Desktop changes don't impact embedded builds.
Embedded work doesn't slow down desktop developers.
Community Contributions
Eventually, anyone should be able to build their own target without modifying the compiler itself.
Introducing AiOS
One of the biggest beneficiaries of this architecture is something I've hinted at for a while:
AiOS.
AiOS is an experimental operating system target built around the AiVM runtime.
Instead of publishing an executable that runs on another operating system, the goal is to publish a complete bootable image that contains only what's necessary to run an AiLang application.
Think of it like this:
Instead of asking:
"How do I deploy my application onto an operating system?"
AiOS asks:
"What if the application is the operating system?"
Early development is focused on QEMU while the platform matures, with additional hardware targets planned later.
Running Natively...
One of the exciting parts of this milestone is that the exact same AiLang application already runs natively.
Native macOS
No code changes.
Same language.
Same application.
Different target.
...and Running Under AiOS
Now that Targets have been separated, that same application can also run inside AiOS.
It's still early.
There's a tremendous amount of work ahead.
But seeing AiLang applications boot inside an operating system built specifically around the AiVM is an exciting milestone.
Looking Forward
Separating Targets from the compiler opens the door for far more than AiOS.
Future targets could include:
- Linux
- Windows
- macOS
- WebAssembly
- Raspberry Pi
- BeagleBone
- Embedded ARM devices
- Cloud microservices
- Kiosk systems
- Virtual appliances
- Experimental hardware
- Community-developed platforms
Each one can evolve independently while sharing the same compiler and deterministic virtual machine.
Building an Ecosystem
One thing I've learned while building AiLang is that good architecture is usually about removing responsibilities, not adding them.
Today the ecosystem is becoming much clearer.
- AiLang defines the language.
- AiVM executes deterministic bytecode.
- AiVectra provides a deterministic vector-based UI framework.
- Targets understand how to build and publish for specific platforms.
- AiOS is one possible target built on that foundation.
Each project has a well-defined responsibility.
Each can evolve independently.
That's a much healthier architecture than trying to build everything into one monolithic toolchain.
The Road to 0.0.1
This work is part of the ongoing effort to stabilize the project as we move through the 0.0.1 Release Candidate series.
It's one of those milestones users may never directly notice—but it's the kind of architectural improvement that makes the project easier to maintain, easier to extend, and easier for others to contribute to.
The language remains focused.
The virtual machine remains deterministic.
Platforms become modular.
That's exactly where I want AiLang to be as we move toward the first stable release.
If you've been following the project, thank you for coming along on the journey.
And if you're just discovering AiLang, now is a great time to take a look. The architecture is beginning to settle, and some exciting things are coming next.
Learn More
If you'd like to follow the project or get involved, here are the best places to start:
- Website: AiLang.Codes
- GitHub Organization: Github
- GitHub Sponsors: Sonsorship
Feedback, bug reports, feature ideas, and contributions are always welcome. As the project moves through the 0.0.1 Release Candidate series, community feedback is helping shape the path toward the first stable release.
Top comments (0)