EOLANG: A Pure Object-Oriented Language That Rejects Classes, Types, and NULL

What EOLANG Eliminates and Why

EOLANG is not another Java or Python. The README lists a dozen features that the authors say they do not tolerate: types, static methods, classes, implementation inheritance, mutability, NULL, global scope, type casting, reflection, scalar primitives, annotations, operators, and even flow control statements like for, while, and if. The project is explicit that even Smalltalk, Eiffel, Self, and Io are not pure enough. The intended audience is a programmer who believes that object-oriented programming has never been done correctly. This is a niche, but it is a passionate one. If you are happy with mainstream OOP, EOLANG will feel like a rejection of everything you know. If you have read the Elegant Objects book, this language is the logical endpoint of that philosophy.

Phi-Calculus as the Foundation

EOLANG is grounded in phi-calculus, a mathematical model described in an arXiv paper linked from the README. In phi-calculus, every entity is an object with named attributes, and objects are formed by applying other objects to void attributes. This is different from lambda calculus, which underpins Haskell, and from class-based models like Java or C++. The key consequence is that there is no separate notion of a function or a method. Everything is an object, and the only way to reuse behavior is through decoration. The special attribute @ points to another object, and the decorated object inherits all attributes of that target. This is not inheritance in the class-based sense; it is composition at the object level. The README gives the example of an object app that decorates stdout, so app behaves like stdout but can add its own attributes. This is a radical simplification, but it also means you must rethink even basic control flow.

Getting Started: Commands and Syntax

The quick start requires Java SE and npm. You install the eoc compiler globally with npm install -g eolang@0.37.1. A minimal program is a file app.eo with [args] > app and a stdout object as the @ attribute. You compile with eoc --easy link and run with eoc --easy --alone dataize app. The README warns that linking may take up to a minute. The syntax is indentation-sensitive, like Python, with two spaces per nesting level. You can also use horizontal notation and brackets to group arguments. For example, stdout > [] > app is a valid alternative. The language has no operators, so arithmetic like x.as-number.times x.as-number is expressed as method calls on objects. The iteration example uses malloc.for, while, seq, and put, all as objects. This is a steep learning curve: even a simple loop requires understanding of memory allocation and sequencing as objects.

The Compilation Pipeline: From EO to XMIR

The parser is a spec-driven implementation. The grammar is defined in eo-parser/PARSER_SPEC.md, with numbered rules R-N.M that the parser references directly. The reference implementation lives in eo-parser/src/main/java/org/eolang/parser/ and converts EO source to XMIR in a single pass with no intermediate AST. XMIR is a dialect of XML that represents an EO program. This is a notable design choice: instead of a traditional AST, you get an XML document. The README points to an XSD and a spec for XMIR. This means every EO program is also an XML document, which could be useful for tooling but also adds a layer of complexity. The parser is written in Java, so the entire toolchain is JVM-based, but the compiler eoc is distributed via npm. This hybrid is practical but unusual.

Limitations and Failure Modes

The most obvious limitation is the lack of types. The README links to an essay on typing without types, but the practical consequence is that many errors that a type system would catch at compile time are deferred to runtime. The iteration example shows that even a simple loop requires malloc.for, which suggests manual memory management is exposed at the language level. The release notes mention a bug where Phi.chunk is not probed, causing malloc.of to fail with ClassNotFoundException. That is a concrete failure mode: the runtime can throw Java exceptions, leaking implementation details. Also, the language is experimental, so the API is unstable. Recent releases show changes to lint rules, like bad-test-name, and internal naming changes. The README says the language is experimental, and the version number is still 0.x. You should expect breaking changes between releases.

Alternatives: Comparing Approaches

The closest philosophical alternative is Smalltalk, which also treats everything as an object, but Smalltalk still has classes and inheritance. EOLANG explicitly rejects Smalltalk as not good enough. Another alternative is Haskell, which is based on lambda calculus and uses types extensively. EOLANG rejects types, so it is at the opposite end of the spectrum. For a practical pure OOP language, you might look at Self, which is prototype-based and has no classes, but Self does have mutable slots and a more traditional runtime. EOLANG goes further by removing mutability and NULL. The key difference is that EOLANG's formal foundation is phi-calculus, not lambda calculus or prototype theory. If you want a language that is formally pure and minimal, EOLANG is unique. If you want a language that is practically usable today, you would choose a mainstream language and accept its impurities.

Maintenance and License

The project is licensed under MIT, which is permissive and allows commercial use with attribution. The repository is not archived, and the last push was in August 2026, so it is actively maintained. Releases are frequent, about once a month, with version 0.63.0 in August 2026. The release notes indicate a focus on lint rules and runtime fixes, not new features. This suggests the project is stabilizing, but it is still pre-1.0. The maintenance cost for a user is high: you must track release notes and adapt your code to breaking changes. The parser spec is a living document, so you need to check it when upgrading. The eoc compiler version is pinned in the quick start, which implies that newer versions may not be compatible. If you embed EOLANG in a larger system, you also need to manage the Java runtime dependencies, as shown by the eo-runtime and eo-parser modules.

Editorial conclusion

Adopt EOLANG if you are a researcher or a hobbyist who wants to explore a language that eliminates classes, types, mutability, and NULL entirely, and you are comfortable with an experimental toolchain that requires Java and npm and may change without notice. Do not adopt it for production systems or for teams that need familiar OOP constructs like inheritance or static methods. Before committing, verify the current version of the eoc compiler, check the latest release notes for breaking changes, and review the PARSER_SPEC.md to see if the language shapes you need are stable. EOLANG is a serious experiment, not a practical language yet.

Official sources

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