Arturo: a stack-based scripting language with no reserved words at all

Code is a list of words, and words mean whatever the context says

The language is described as an independently developed, modern programming language, vaguely related to various other ones, and the list is long and revealing: Logo, Rebol, Forth, Ruby, Haskell, D, Smalltalk, Tcl and Lisp.

The design principles are stated as three simple rules. Code is just a list of words, symbols and literal values. Words and symbols within a block are interpreted, when needed, according to the context. And there are no reserved words or keywords, with the instruction to look for them as hard as you can, because there are absolutely none.

That third principle is the one that defines Arturo, and it has a real cost and a real benefit. The benefit is that a script never collides with a language keyword, and there is no list of words you cannot use as a variable name. The cost is that you cannot read a program and know what a word does without knowing the context, which is why the documentation leans so heavily on examples.

The example in the README shows the shape of the thing:

factorial: function [n][
	switch n > 0 -> n * factorial n-1
	             -> 1
] 

loop 1..19 [x]->
	print ["Factorial of" x "=" factorial x]

Two features are visible immediately. The switch has no keyword; it is a word that takes a condition, a comparison operator and branches. And the loop body is written as a block that returns a value, with the arrow, which is not a keyword either, marking the block's result.

The topics attached to the repository name the implementation model: stack-based, homoiconic, bytecode, interpreter, virtual machine, and functional programming among them. The stack discipline is the reason a multiplication looks the way it does, since n * factorial n-1 operates on values that have been pushed.

The stack is why the syntax looks the way it does

The consequence of a stack-based design is that everything is a word applied to a stack, and the only way to structure a program is with blocks that return values.

Look at the print call in the example. The arguments are collected in a bracket expression and the words inside a block are what get evaluated. The factorial definition takes a parameter list in square brackets and a body in another, and the body's value is the value of the block.

This is the Forth and Rebol family of languages, and Arturo is candid about the resemblance. What it adds is the mixture of symbols, the range syntax in the loop, and the switch construct with a comparison in the middle.

For someone coming from a mainstream language, the adjustment is real. There is no expression grammar in the usual sense, so a line like the factorial recursion does not have an obvious left to right reading. A parenthesised call in Arturo is not a function call, it is a block, and its value is what it returns.

The payoff is that the whole language is very small. The principles section fits in three bullets, and the documentation leans on the official website for the language reference rather than repeating a grammar in the README. A stack language with no keywords is a language you can learn in an afternoon, which is exactly the point of a scripting language.

The homoiconic label in the topic list means the data representation of the program is the same as the data it manipulates, which is what makes a stack machine that can run its own source a sensible design rather than a stunt. The bytecode and virtual machine topics indicate the implementation is a compiler to bytecode run by a VM, which is the part that makes the language portable across operating systems.

Installing it is a curl pipe, and the language ships as a single binary

Installation is unusually frictionless, and the README is honest that it is barely an installation at all.

Arturo comes with its own pre-built binaries for practically all operating systems, so technically it does not require any installation. You download one and run it. There is a download link on the official site, and for people who want the most recent build there is a separate nightlies repository with the latest release.

The alternative way is a single command:

curl -sSL https://get.arturo-lang.io | sh

For Unix and Mac, copying and pasting that into a terminal installs the most recent stable version. To get the most recent nightly build instead, the URL ends in /latest. The pipe-to-shell pattern is standard for language installers of this kind, and the difference between the stable and nightly channels is one path segment.

There is also a Docker image, and the README is careful about what it is for. It says the Docker image will not cut it if what you need is the real-deal compiler for everyday use, but if you just need a taste of it, the image will do. Two invocations are given:

docker run -it arturolang/arturo

docker run -it -v $(pwd):/home arturolang/arturo <yourscript.art>

The second one mounts the current directory and runs a script from it, which is the form you would use if you were working through a directory of .art files rather than interacting with a REPL.

For macOS there is a Homebrew formula, with the caveat that the author cannot guarantee it will be the latest version:

brew install arturo

And for a manual build the README points at a wiki page with the instructions rather than reproducing them, which is the one part of the installation story that is not self-contained.

The repository is a Nim source tree with its own configuration in Arturo

The implementation is written in Nim, and the repository layout shows a language project rather than an application.

At the top level there is a src directory holding the implementation, a tests directory, a tools directory, a docs directory with images, a version directory, a bin directory, and a build.nims file that is the Nimble build script. There is also config.nims and a config.art.

That last file is worth pausing on. The project carries a configuration file written in Arturo itself, alongside the one written in Nim. A language that can configure its own build is a fairly strong statement about the design, and it is a practical one, since the build configuration is then editable without learning the host language's build syntax.

The presence of an AGENTS.md file and a.config directory suggests the project is set up for contributors working with coding assistants, and there is a.tokeignore file, an exclusion list for code counting tools.

The primary language on the project record is Nim, and the licence is MIT. The repository is not archived, and the last push was on 2026-09-10.

The release history is the part that needs interpreting. The most recent tagged release is v0.10.0, named Arturo v0.10.0 Arizona Bark, dated 2026-01-15. Before that, the two most recent tags are v0.9.83 and v0.9.82, both from February 2023. So the project was on the 0.9 line for a long stretch, has moved to a 0.10 line, and has had commits since the January 2026 tag without a new tag following them.

For an adopter that means the stable entry point is the 0.10.0 release, and the master branch is ahead of it. That is normal for a language with a single maintainer, and the nightlies repository exists precisely to serve people who want the tip.

The ecosystem is two small projects written in Arturo

The examples section of the README points at other projects by the same author, and they tell you more about the language's intended uses than a feature list would.

The first is Grafito, described as a portable, serverless and lightweight SQLite-based graph database. The second is Aguila, described as a modern cross-platform webview.

Both are written in Arturo, and both are the kind of project a stack language with a small standard library makes possible: a self-contained binary, no runtime to install, no external services beyond what the script talks to. A language that compiles to a single executable and starts instantly is a good fit for a tool you run occasionally, and a poor fit for a service you deploy with a runtime version to pin.

The project documentation lives on the official website rather than in the repository, split into Getting Started, In A Nutshell, Language, Command Line, Library and Examples pages. The examples page is the one the README points to directly for working code, which is the sensible default for a language whose parsing depends on context.

There is also a Discord community linked in the README, and the contributing section describes a repository activity tracker and how to contribute. The repository has a CONTRIBUTING-style structure with the.github directory, a CODEOWNERS file is not mentioned but the.config directory suggests a structured contribution setup, and there is a donations section.

The library reference is on the website rather than in the source tree, which is a common arrangement for a language whose standard library is small enough to document in pages.

Where Arturo is the wrong choice

Three situations rule it out, and none of them is about the language being badly designed.

The first is a team that needs the ordinary safety net. Arturo has no type system to speak of, no static analysis, and a syntax whose meaning depends on context. That is a legitimate design for a scripting language, and it is exactly what you do not want in code that other people maintain, that has to be reviewed, or that a static analyser has to check. The MIT licence and the small footprint do not compensate for a codebase nobody but the author can confidently modify.

The second is the release cadence. A single tagged release since 2023, and one in January 2026, with commits continuing since. For a scripting language that is often tolerable, because a script either works or it does not and you can patch it. For anything you intend to build on, a language whose interface may change between the tag and the branch you cloned is a cost you take on knowingly.

The third is that Arturo is not a general purpose language yet. The library reference is on a website, the ecosystem shown in the README is two projects by the author, and there is no package manager in the picture at all. That is fine for a scripting language whose whole point is to have everything in one file, and it is disqualifying if you expect to compose your work from maintained third-party modules.

There is a smaller point about the Docker image, which the README itself makes. The image is not the real-deal compiler for everyday use. If you are containerising, the pre-built binary is the better artefact, and the Docker route is a convenience for trying the language rather than a deployment strategy.

Editorial conclusion

Arturo fits a scripter who wants a small, fast, self-contained language with a REPL and a compact syntax, and it fits someone who wants to read a language implementation that is small enough to understand, since the repository is a single Nim source tree with a tests directory. It is the wrong choice for a team that needs a mainstream language with a large package ecosystem, strong typing guarantees and a decade of tooling, and it is the wrong choice if you need a stable versioned release, because the last tagged release is v0.10.0 from 2026-01-15 while the last push was on 2026-09-10. Before adopting it, run the factorial example from the README in the REPL to feel the stack discipline, and read the wiki page on building Arturo, because the manual build path is the one the README points to rather than documenting inline.

Frequently asked questions

Official sources

1. arturo-lang/arturo on GitHub
2. License: MIT
3. Project website
4. README
5. Releases