Desktop and server

Targets

AEL 1.0.0 builds for Linux on x86-64 and ARM64, macOS on Apple silicon (ARM64) and Windows on x86-64. Single-board computers and servers that run Linux on ARM64 or x86-64 are Host targets too. Supported targets gives the target names.

Building and running

ael build builds the executable for the target you name, and ael run checks, builds and runs a program in one step:

ael build --target linux-arm64 -o build/support --release
ael run

• Self-contained. The AEL toolchain is self-contained: one install takes your AEL code all the way to a native program. Desktop and server programs written in AEL alone need nothing else installed.
• Named after your application. The executable takes the name that main carries, such as support for main support(), unless -o names another file.
• Only what you reach. The executable holds only what your program reaches from main.
• Verifiable. Each build records exactly what went into it, so you can check what a program contains.

Building a program describes every build option.

Functions in other languages

Your application can hold private functions written in other languages, with typed AEL signatures, built and run with your own toolchains, pinned by version. Their compiled code sits beside the executable, and the machine that runs it needs the runtimes those functions use, at the versions they pin. A function in another language runs on the same machine by default or in a sandbox, which needs the isolation facilities of Linux and runs only on the Linux target the documentation names for it, and a missing toolchain, a wrong version or a missing sandbox is refused before anything runs. Functions in other languages describes them, and Supported targets names the target where the sandbox runs.

Static Linux executables

Programs build into standalone native binaries, including static Linux binaries. A static Linux executable does not depend on the shared libraries of the machine it runs on. Files it needs at run time, such as the trust roots it uses to verify TLS certificates, are included on purpose rather than assumed to be on the machine.

Static executables are also what goes into minimal container images.

The runtime

A multi-core, nonblocking runtime needs no thread per user, and programs that don't need worker threads don't get them.

• Bounded workers. Worker threads are bounded by the machine's processing capacity, and their number never grows with the number of users or requests.
• One handler per agent. Each agent instance handles one message at a time, even when many worker threads run, so its state is never changed by two handlers at once.
• Waiting holds no worker. Slow network calls wait without holding a worker, work that has to block runs in a separate bounded pool, and a cancellation reaches work that is waiting.
• Many tenants. Agents are multi-tenant from the start: a trusted tenant identity flows through every call, store, log and reply, with fair scheduling and predictable behaviour under overload.

Concurrency describes agents, mailboxes and cancellation in the language.

Resource limits

Per-agent CPU and memory limits state whether each limit is hard-enforced or accounted.

• Accounted: agents that share one process are measured and limited by the program itself.
• Hard-enforced: an agent in its own process group, on an operating system that can enforce it, gets limits that the operating system enforces.
• A request for a hard limit the deployment cannot enforce is refused when you deploy, never silently weakened.
• A CPU limit caps processing; it does not guarantee a deadline.

Budgets, retries and validation describes how limits combine across tenants, agents and runs.

Source-level debugging

You debug at source level in standard native debuggers. Build with --debug, then open the executable in the debugger you already use:

ael build --target linux-x86_64 -o build/support --debug

• Your source. Breakpoints, stepping and stack traces point at your AEL files and lines, including the helper functions in a component's extension files.
• Matched or refused. Debugging information that does not match the executable and its source is refused, rather than showing the wrong lines.
• Honest values. A value that the build optimized away is shown as such, never invented.
• Same code. --debug adds information only; the program's code stays the same as in a build without it.

Console, files and processes

A console program reads its input from its arguments, standard input or the console, and writes its answer to standard output. See Console and logging and Files and processes.

Related

• Containers: the same program in a minimal image.
• Deployment and rollback: putting a new version into service.
• Logging and monitoring: logs, health and resource use.