Desktop and server

Targets

Planned for Beta 0.0.1: 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 will be Host targets too. Planned targets gives the target names.

Building and running

ael build (command names may change before launch) will build the executable for the target you name, and ael run will check, build and run a program in one step:

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

• Self-contained. The AEL toolchain will be self-contained: one install will take your code all the way to a native program. Desktop and server programs will need nothing else installed.
• Only what you reach. The executable will hold only what your program reaches from main.
• Verifiable. Each build will record exactly what went into it, so you can check what a program contains.

Building a program describes every build option.

Static Linux executables

Programs will build into standalone native binaries, including static Linux binaries. A static Linux executable will 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, will be included on purpose rather than assumed to be on the machine.

Static executables will also be what goes into minimal container images.

The runtime

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

• Bounded workers. Worker threads will be bounded by the machine's processing capacity, and their number will never grow with the number of users or requests.
• One handler per agent. Each agent instance will handle one message at a time, even when many worker threads run, so its state is never changed by two handlers at once.
• Waiting will hold no worker. Slow network calls will wait without holding a worker, work that has to block will run in a separate bounded pool, and a cancellation will reach work that is waiting.
• Many tenants. Agents will be multi-tenant from the start: a trusted tenant identity will flow 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 will state whether each limit is hard-enforced or accounted.

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

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

Source-level debugging

You will 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 will 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 will be refused, rather than showing the wrong lines.
• Honest values. A value that the build optimized away will be shown as such, never invented.
• Same code. --debug will add information only; the program's code will stay the same as in a build without it.

Which targets offer source-level debugging, and with which debugger formats, will be listed with the final list of targets.

Console, files and processes

A console program will read its input from its arguments, standard input or the console, and write 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.