DEV Community

Cover image for I built Soul, a tiny compiled language that generates ~22KB binaries — here's what I learned
RobeLTDP
RobeLTDP

Posted on

I built Soul, a tiny compiled language that generates ~22KB binaries — here's what I learned

#programming #linux #automation #showdev

I've been working on a small compiled language called Soul.

It didn't start from benchmarking existing tools. It started from a simpler question:
how small and fast can a compiled language be if it's designed to do just a few things well?

The idea

Most filesystem automation lives in two uncomfortable places: Bash scripts that get fragile at scale, or full programs in Go or Python that feel heavy for simple tasks. Soul explores a more declarative way of describing filesystem operations.

The language understands the filesystem as a structure — trees, differences, missing files — rather than just running commands against it.

What it looks like

backup.soul (full file)

str src = arg("--folderSrc")
str dst = arg("--folderDst")
printStr("Starting backup...")
mkdir(dst)
backup(src, dst)
Enter fullscreen mode Exit fullscreen mode

_overview.soul _(full file)

str folder = arg("--folder")
overviewinfo ov = overview(folder)
str txt = overviewSummary(ov)
printStr(txt)
Enter fullscreen mode Exit fullscreen mode

These samples compiles to static binaries of about 22KB and 17Kb respectively, with no runtime and no external dependencies.

Some numbers from local tests on Linux + NVMe:

  • ~210K file scan: 0.39s
  • Incremental copy of ~1.4GB: 1.9s
  • Docker image (FROM scratch): ~68KB

These are honest local runs, not microbenchmarks.

Something I'm experimenting with: plan mode

One idea I'm exploring is a "plan mode" — where Soul analyzes the program before executing it and tells you exactly what will happen: which files will be copied, deleted, or modified, and how much data is involved.

Not a dry-run flag on top of existing commands, but something built into the language model itself. Deterministic and inspectable before anything touches the filesystem.

This feels like the most interesting direction to me, especially for large or destructive operations where you want visibility before you commit.

Where it lives today

There's a browser-based editor and compiler at soul-run.com where you can write Soul code and download the resulting binary. You can also download test binary files:

https://soul-run.com/binary.download?file=overview
Usage:

chmod +x overview
./overview --folder "/your/folder"
Enter fullscreen mode Exit fullscreen mode

https://soul-run.com/binary.download?file=backup
Usage:

chmod +x backup
./backup --folderSrc "/your/source/folder" --folderDst "/your/destination"
Enter fullscreen mode Exit fullscreen mode

The compiler is currently closed-source while I stabilize the language design.

You can also try the backup tool directly with Docker:

docker run --rm \
  -v /your/source:/src \
  -v /your/destination:/dst \
  soultools/backup:latest \
  --folderSrc /src --folderDst /dst
Enter fullscreen mode Exit fullscreen mode

Or the overview tool:

docker run --rm \
  -v /your/local/folder:/data \
  soultools/overview:latest \
  --folder /data
Enter fullscreen mode Exit fullscreen mode

What I'm still figuring out

Honestly, I'm not sure yet what Soul should become. The binary size is interesting, but the declarative model and the plan mode feel like the more compelling direction. I'm also considering focusing into IoT since ultralight binaries could work great in small and light devices.

I'd love to hear from people working with large filesystem workflows, backup automation, or language design: does this resonate? Are there domains beyond filesystem operations where this model could make sense?

More info: https://soul-run.com/

Top comments (0)