The demo (httpd.flx) compiles down to native x86-64, and the resulting server runs with no C runtime/libc dependency (it uses direct syscalls on macOS and Linux, and Winsock plus Kernel32/WS2_32 on Windows).
If you want to poke around you can clone the repo, build it (the compiler is just a Node.js script, very inspectable), and test it with a simple curl localhost/health or curl localhost/ . You can also inspect the native machine code with tools like otool -L on macOS to verify the lack of Mach-O dynamic-library dependencies.
The reason I chose a tiny HTTP server was it shows an actual socket lifecycle (accept/read/respond/close), but it doesn't pretend to be production-grade.
If you look at examples/httpd.flx[0] you can ysee how eveyrthing works - and how the language models the failure states. Why build a new language? The hypothesis is that explicit external-failure and concurrency semantics may be easier to inspect and audit, including for code-generating tools.
Where is this project? It is:
- highly experimental
- very limited, targeting only x86-64
- server is serial
- recognizes two fixed GET route prefixes and returns a demo 404 otherwise
- no TLS, keep-alive, or streaming
- making no performance claims and has had no security audit
My hope is this is small enough that people look at it, but substantial enough that it demonstrates the possible future directions and potential of the language.
I'm interested in thoughts on the approach: is the failure modeling clear enough in the example (IMO, the chaos tags could be decorated better), and does it look easier to audit?
[0]: https://github.com/DO-SAY-GO/freelang/blob/main/examples/htt...