egua: a programming language whose syntax is entirely Portuguese

A language built for teaching, with Portuguese keywords

Egua is described in the repository description as a simple and modern programming language, and the README makes its purpose explicit: it is an interpreted programming language with entirely Portuguese syntax, aimed at teaching programming.

That last phrase is the whole design brief. The language name is Égua, and the vocabulary is Portuguese throughout: escreva to print, importar to import a library, matematica for mathematics, textos for text handling, tempo for date and time, requisicao for HTTP requests. Even the REPL prompt is Portuguese, showing égua> before each line.

The audience is therefore learners whose first language is Portuguese, and teachers who want students reading code in the language they speak. That is a narrow but real audience, and the choice removes the initial friction of a second language sitting between a beginner and the idea they are trying to learn.

It also means the library cannot be a drop-in for anyone else. There is no way to use egua in an English speaking codebase, because every keyword and every standard library name is Portuguese. That is a feature for its target users and a hard boundary for anyone else.

The project is hosted on npm as egua under the MIT licence, with the documentation site at egua.dev and the online IDE at programar.egua.dev.

Lexer, parser, resolver and a tree-walking evaluator in JavaScript

The interpreter is written in JavaScript, and the README describes its parts: lexer, parser, resolver and a tree-walking evaluator. That is a conventional front end for a small interpreted language, and the tree-walking design is a deliberate simplicity choice rather than a bytecode virtual machine.

The practical consequence is that source text maps fairly directly onto execution. There is no compilation step in the pipeline, so a program runs as soon as it is parsed, and a stack trace points at a node in the syntax tree rather than at an instruction in a generated bytecode stream. For a teaching language that is the right trade, because the machine has no hidden stage between the student and the result.

The repository layout in the README shows how the parts are separated. The src/ directory holds the core of the language, the lexer, parser, resolver, interpreter and the standard libraries. The bin/ directory is the entry point for the CLI, and the scripts/ directory builds the browser bundle of the language using esbuild. The package.json lists esbuild as the only development dependency, which tells you the browser build is a bundle step rather than a separate toolchain.

The package itself is small in packaging terms. The files field lists bin, src and index.js, the type field is module, and the bin field maps the egua command to bin/egua, so the CLI is the package's public surface alongside the browser bundle.

One interpreter, two environments: terminal and browser

The interpreter runs in two environments, and the README is specific about how each one is used.

In the browser you do not install anything. You visit IDEgua at programar.egua.dev and start programming in the editor, which suggests keywords and functions as you type, and you can open the suggestions manually with Ctrl and Space, or Command and Space on macOS. The IDE consumes the language bundle that the scripts/ build produces, which the development instructions describe as apps/idegua/js/egua.min.js.

Locally, with Node.js 18 or later installed, one global install gives you the egua command:

npm i -g egua

That command does two things. With a file argument it runs the program, and with no arguments it opens the interactive REPL:

# Executa um arquivo .egua
egua meu_programa.egua

# Sem argumentos, abre o modo interativo (REPL)
egua

In the interactive mode each line is executed straight away:

égua> escreva("Olá, mundo!")
Olá, mundo!

Running the same two lines as a file gives the same output, and the file extension is.egua:

escreva("Olá, mundo!");

which you then run with egua ola.egua. The REPL is the more interesting of the two for a classroom, because a teacher can type a line, change it and show the difference without saving a file.

Four standard libraries and a small set of global functions

The standard library is imported with importar, and the README lists four native libraries in a table. matematica covers mathematical functions such as the square root and trigonometry, textos handles text manipulation such as upper case, splitting and substitution, tempo gives access to system date and time, and requisicao performs HTTP requests with the functions obter, enviar, atualizar and excluir, which map to the usual get, post, put and delete operations.

A library is loaded like this:

var m = importar("matematica");
escreva(m.raizq(16)); // 4

The name raizq is the Portuguese abbreviation for square root, and the call returns 4, which tells you the library is an ordinary object with methods rather than a set of global functions.

Alongside the libraries, there are global functions that are always available, named in the README as escreva, texto, paraCada, mapear, filtrar e ordenar. Those are print, text, forEach, map, filter and sort, and the Portuguese names again remove the need for an English vocabulary layer in a first program.

The complete reference is on the documentation site. The README does not enumerate the members of the standard libraries beyond the examples, so if you need a specific function you will be reading the reference rather than the README.

The test suite is a program written in the language

The repository is a monorepo, and the README describes each path in a table. src/ is the language core, bin/ is the CLI entry point, tests/ holds the test suite, scripts/ builds the browser bundle, apps/site/ is the site and documentation built with VitePress, and apps/idegua/ is the online IDE.

The detail worth pausing on is the test suite. The README describes tests/ as a suite written in the language itself, tests.egua, and the package.json confirms it: the test script runs the interpreter over the test file, with the test command being./bin/egua tests/tests.egua.

That is a self-hosting arrangement. The interpreter is tested by running programs written in the language the interpreter implements, which means the test harness needs no second language and no test framework, and it means the language's own syntax is exercised at every level of the implementation. It also means a bug in the parser can break the test suite itself, so the failure mode is not always clean.

Development locally follows the same pattern. The clone, install, test and run sequence is:

git clone https://github.com/eguadev/egua.git
cd egua
npm ci

# Roda a suíte de testes da linguagem
npm test

# Executa a sua cópia local do interpretador
./bin/egua meu_programa.egua

and the browser bundle is regenerated with npm run build-web. The documentation site has its own workflow, running npm ci and npm run dev inside apps/site.

Licence, release pace and the limits of the ecosystem

The licence is MIT, with the LICENSE file at the repository root and the license field in package.json set to MIT. MIT is permissive, so anyone can use, modify and redistribute the interpreter.

The release cadence is fast for a young project. The tagged versions are v1.3.16 from 2026-08-30, v1.3.15 and v1.3.14 both from 2026-08-29, and the package version in package.json is 1.3.16. The repository is not archived and the last push was on 2026-10-16. Patches arriving within a day of each other is the profile of a project iterating on its own release, so pinning a version rather than tracking latest is the safer habit.

The limits are the limits of a small teaching language. There is no package ecosystem to speak of beyond the interpreter itself, no module system beyond the four native libraries, and no published language specification that the README points to. The documentation site at egua.dev/egua is the reference, and the README does not point to a formal language specification beyond it.

The obvious question for an evaluator is whether a beginner who learns egua can then transfer to a mainstream language. The answer is not documented in the README, and the deliberately different vocabulary makes that transfer less direct than for a language that borrows English keywords. What the project offers is a first language in which the concepts are visible, at the cost of isolating the learner from the syntax they will meet in every other language.

Editorial conclusion

Egua fits a classroom or a self-learner who wants to think in their own language while writing code, and it fits a teacher who wants an IDE that needs no local install, since the browser version is a single bundle served by IDEgua. It is the wrong choice for production software, for anyone who needs the wider ecosystem around JavaScript, or for a team that needs a specification and a mature standard library, since the language ships four standard libraries and a set of global functions. Before adopting it, read the documentation at egua.dev/egua, install it locally with npm i -g egua on Node 18 or later, and try the REPL to see whether a Portuguese keyword set is what your learners actually need.

Frequently asked questions

Official sources

1. eguadev/egua on GitHub
2. License: MIT
3. Project website
4. README
5. Releases