I wanted this to be "compiled to machine code Node JS" but after I got started I realized I could create any syntax and concurrency model I wanted.
The FSABI model I settled on (where parallel job inputs and outputs are files) ended up being easily applicable across linux/macos `fork()` and win32 `CreateProcess` while maintaining auditability.
Some motivations and design decisions I have for this:
- fail-fast semantics. Programs should be correct, any bug is a fatal error. The "last bug you'll ever see" philosophy. External conditions are not errors or bugs, they are modeled states. Every freelang program immediately exits with "fall <message>" a bug is encountered. This is no error recovery.
- value audit-ability, and easy-to-reason about, concurrent semantics over raw-throughput or memory efficiency. Let the OS carry the weight of task scheduling because it's good at it, rather than writing our own trampoline or event loop. Clarify inter process boundaries: no shared memory, inputs and outputs are passed through the filesystem. Every job has a "job directory" where it can be replayed, and even signed for a cryptographic audit trail.
- no libc, etc. Avoid a giant black box of libc vulnerabilities and legacy baggage. Nothing but syscalls/kernel32.dll. Some things will eventually require an external library (HTTP/2, TLS, maybe BearSSL), but simpl HTTP, Net are fully available via syscalls/Win32 kernel.
- Output raw assembly to keep it straightforward, auditable and concise. We have an clear IR, and multiple backends (currently Linux ELF opcodes, and Macho ASM, both x86_64, and currently working on the same for Windows PE). 250+ tests already.
- And many other little choices that make this unique.
Ultimately it will be a fully cross platform minimal systems scripting language with a security and audtiability focus. It can eventually replace bash glue, Python glue, and other scripts. Particularly targeted at small vendors who don't want to give a client a bash script, and have them never pay again, as client just takes over "maintenance". It's valuable in industries where strict audibiility, and deterministic fail states (no limping) are important.
The future road map includes the integration of the AMULET licensing system currently used for BrowserBox to permit these tiny binaries (minimal tests are commonly 10KB), to have license enforcement capabilities to increase payment compliance.
We have a basic mark and sweep GC (currently full on Linux, and safepointed on Macos) and a bump allocator used everywhere. Our memory layout is deterministic, and the compiler has basic runtime-tree-shaking capabilities. Don't allocate to heap? You get a deterministic stack with no GC/allocator in the executable. Don't use files? The FS intrinsics are omitted. And so on.
The FSABI model I settled on (where parallel job inputs and outputs are files) ended up being easily applicable across linux/macos `fork()` and win32 `CreateProcess` while maintaining auditability.
reply