EOLANG: objectionary/eo, a pure object-oriented language without types or classes

What EOLANG removes, and who that is for

EOLANG is an experimental object-oriented language built on 𝜑-calculus. Its README lists what the authors refuse to tolerate, and the list is long: types, static or class methods and attributes, classes, implementation inheritance, mutability, NULL, global scope, type casting, reflection, scalar primitives, annotations, operators, traits and mixins, and flow control statements such as for, while and if. That is not a style guide. It is the language definition.

The audience follows from that. This is for people who want to write programs where the only reusable mechanism is decoration: an object's @ attribute points at another object, and the outer object inherits the inner one's attributes by composition rather than by subclassing. It is also for researchers, since the README points to papers and to XMIR, an XML dialect used to represent EO programs. It is not for a team that wants a typed interface between services or a large pool of hires. Removing classes and types is the whole point, so anyone who needs them is in the wrong repository.

From EO source to XMIR: the parsing pipeline

The repository is a Maven multi-module project. The modules that matter for the language itself are eo-parser, eo-printer, eo-lowering, eo-runtime, eo-inference and eo-maven-plugin, with eo-integration-tests alongside them. The parser module holds the reference implementation under eo-parser/src/main/java/org/eolang/parser/.

According to the README, that parser converts EO source to XMIR in a single pass with no intermediate AST. There is no tree of nodes to walk afterwards; the source is classified line by line into XMIR directly. The grammar is written as a spec in eo-parser/PARSER_SPEC.md, with numbered rules of the form R-N.M that the parser code references. That is an unusual arrangement. Instead of a grammar file that generates a parser, the spec and the implementation are kept in step by hand, and the rule numbers are the link between them.

Indentation is significant, as in Python. Two spaces move a line one level deeper. The README notes that horizontal notation is also allowed, so `stdout "Hello, world!"` means the same as writing stdout and the string on separate lines. The @ attribute is special: it marks the object being decorated, which is how `app` in the first example comes to behave like `stdout`.

Installing eoc and running a first program

The README's Quick Start requires Java SE and npm first, then the eoc command-line compiler, installed globally from the eolang package. The version pinned in the README is 0.37.1, which is older than the 0.63.0 release listed in the repository, so treat the pin as the documented example rather than the current version.

npm install -g [email protected]

With eoc on the path, create app.eo. The README's first program is an abstract object named app with a single @ attribute pointing at a copy of stdout:

# Just prints hello.

[args] > app
  stdout > @
    "Hello, world!\n"

Compile it. The README warns this may take up to a minute or so:

eoc --easy link

Then run it with dataize, which is the step that actually produces output:

eoc --easy --alone dataize app

You should see "Hello, world!" printed. Note the two distinct commands. link prepares the program, dataize evaluates it, and the --easy flag selects the simplified workflow the README uses throughout. The README does not document what --easy changes compared with the default mode, so if you need to understand the build graph, that is a gap to fill from the source.

Iteration without a for loop: malloc.for and while

With no flow control statements, repetition has to be expressed as objects. The README's example builds a counter in a fixed-size memory block and loops over it until a condition fails:

[args] > app
  malloc.for > @
    2
    [^ x] >>
      while > @
        ^.x.as-number.lt 6 > [^ i] >>
        seq * > [^ i] >>
          stdout
            "%d x %1$d = %d\n".printf
              *
                ^.x.as-number
                ^.x.as-number.times ^.x.as-number
          ^.x.put
            ^.x.as-number.plus 1

The README says this prints the multiplication table from 2 to 5. Two things stand out. First, `malloc.for` allocates a memory cell, and mutation happens through `^.x.put`, so the no-mutability rule applies to the language's own objects rather than to the memory the runtime hands out. Second, the loop condition and the loop body are separate objects passed to `while`, each taking an iteration attribute named i. There is no loop keyword to learn, but there is a `while` object, plus `seq` to sequence two actions. The cost is visible in the example: a four-line loop in most languages becomes a nested structure where the counter is reached through `^` up the parent chain.

Where the model gets in the way

The first limitation is the toolchain, not the language. The README's own install path is npm plus Java, and the compiler is distributed as an npm package while the runtime and Maven plugin live in the Java repository. That is two ecosystems to keep aligned. The README pins [email protected] while the repository's recent releases run to 0.63.0, so a reader who follows the Quick Start verbatim is installing a version well behind the current one.

Second, the release notes show how tightly the pieces are coupled. Version 0.62.1 fixes a case where `Φ.chunk` was not probed, causing `malloc.of` to fail with a ClassNotFoundException. Version 0.62.0 notes that eo-runtime test objects were named `tests-…`, which a new `bad-test-name` lint rejected. A lint that breaks your own test object names is a sign the constraints are still being negotiated, which is expected in an experimental language but matters if you depend on it.

Third, the compile step is slow by the README's own admission: up to a minute for a hello-world link. For a language whose selling point is a cleaner object model, that is a real tax on the edit-run cycle. And the absence of types means errors that a type checker would catch at compile time surface later, during dataization.

EOLANG against a class-based language

The nearest comparison is not another experimental language but the one most readers already use: Java. In Java, behavior is reused through class inheritance and interfaces, state lives in fields that can be reassigned, and the compiler enforces types before anything runs. EOLANG takes the opposite position on each of those. There is no implementation inheritance; reuse happens when an object's @ attribute points at another object and thereby takes on its attributes. There are no classes, so an object is defined directly with `[args] > name`. There are no types, which the README defends by linking to an essay titled typing without types.

The practical difference shows up in what you can promise a caller. A Java method signature tells a caller what it gets back. In EO, an object either has an attribute or it does not, and the README's own hello-world example passes `args` that the program never reads. That is not a defect, but it means the contract between objects is structural and discovered at runtime rather than declared. If your problem is coordinating many teams against stable interfaces, class-based languages are the better fit. If your problem is understanding what a program looks like when decoration is the only composition operator, EOLANG is a deliberately narrow answer.

Licence, releases and what upgrading costs

The repository is MIT licensed, with a LICENSE.txt at the top level and a LICENSES/ directory plus REUSE.toml, which suggests REUSE-compliant licence metadata across the tree. MIT is permissive, so embedding the compiler or runtime in a larger system does not by itself impose copyleft obligations. This is a description of the licence files present, not legal advice; check the actual terms and any third-party notices in LICENSES/ before you rely on it.

The repository is not archived, and the last push was on 2026-08-27, which is recent. Releases arrive frequently: 0.62.0 and 0.62.1 landed a day apart in late July 2026, and 0.63.0 followed on 2026-08-27. That cadence is the upgrade cost. Each release can change the runtime and the compiler together, as 0.62.1 shows, where a missing probe for `Φ.chunk` broke `malloc.of`. There is no long-term support line mentioned in the README, so pinning eoc and the eo-maven-plugin to a known pair is the only way to avoid chasing breakage. The npm package and the Java artifacts version independently, which makes that pinning a manual step.

Editorial conclusion

Adopt EOLANG if you want to study or teach a language where decoration is the only reuse mechanism, and you accept that the toolchain is a Java plus npm stack that compiles to XMIR before anything runs. Do not adopt it for production services that need typed interfaces, mutable state or a large hiring pool. Before committing, verify two things yourself: that eoc --easy link completes on your machine within the minute the README warns about, and that the eo-runtime version pulled in by eo-maven-plugin matches the eoc release you installed, since the runtime and the compiler are versioned separately.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes