Questions actually asked, and the answers actually given
Questions people have actually asked, with the answers they were actually given. Nothing here is hypothetical, and nothing here is a roadmap.
Because recursion is a bytecode VM's worst case, and CX's VM is not optimised for it — that is a deliberate ordering of work, not an oversight.
The honest version of the answer is the reason behind it. When you want something fast, you use the native backend — it compiles to C, your C compiler optimises it, and you get C's performance including whatever it does with your recursive function. The VM exists for a different job: code that has to change while the program is running. So VM optimisation work is aimed at the fat, common shapes — loops over arrays, lists, maps and JSON documents — because that is what code-that-changes actually spends its time doing.
Tail-call optimisation would close the specific recursion gap and is understood well enough to cost little; it sits behind the container work rather than in front of it.
Because "compile it" and "change it while it runs" are genuinely different jobs and one implementation cannot be best at both.
cx app.cx --run) compiles your program to C and builds it with your C compiler. It is C: C's speed, C's libraries, C's debugger.cx app.cx --runvm) runs the same source in-process, with no C compiler involved. That is what makes it possible to compile a function from a string at runtime — a rule read out of a config file, or a function a language model just wrote — and attach it to live program state. It is also what runs CX in a browser tab, where no C compiler exists.The two are expected to produce identical output, program for program, and the bulk of CX's test suite exists to check exactly that on Windows, Linux and macOS. A program that is compiled natively can still hand a piece of itself to the VM while it runs; that is the normal arrangement, not an exotic one.
The rule, decided once so it is not re-argued per feature:
"wasm should have its own sandbox where everything that can work — works."
So the question for any capability is never "is this dangerous in a browser" and never "did somebody get round to porting it". It is:
Concretely: file I/O works, and HTTP requests work. system() refuses by name (CX-E5037), because there is no process model in a tab and any number it returned would be fiction. _C{} blocks cannot work there at all and are refused permanently — there is no native binary to hold the C. The AI builtins are native-only and say so at compile time (CX-E1013), because they need a native HTTP client and a key.
Into the tab's own virtual filesystem, and nowhere else. fwrite and fread round-trip normally — as far as your program is concerned it is a real filesystem — and nothing reaches the server's disk or yours. That containment is measured rather than assumed: the test that checks the round-trip also plants a file under a known name and requires the check to go red if it ever appears server-side.
No, and it is worth being precise about it because the two questions get conflated.
CX is free to use, including commercially, and it is publicly downloadable for Windows, Linux and macOS. What you download is a complete working distribution: the compiler binary, the prebuilt runtime library, the public headers, an installer, the manuals and the examples. Credit to CX+AI is required for bundled material; the license file ships with every download.
What the download does not contain is the compiler and runtime source. That stays private. So "free" is accurate and "open source" is not — please do not describe it as open source on our behalf.
No. CX is a general-purpose language: a CX program that never touches a model is an ordinary program, and most of the shipped examples are exactly that.
The AI surface is something CX has, not something it requires. It is there because CX's particular bet is that a program's behaviour is more useful stored as editable data than baked into a branch — and once behaviour is data, a model is simply one more thing that can write it, alongside a config file and a human.
No. cx app.cx --build produces an ordinary native executable for the machine you built it on, which runs like any other program.
Building is what needs the toolchain: CX compiles to C, so the machine doing the compiling needs a C compiler, which the installer sets up and then proves with a real build.
More than most, and by mechanism rather than by diligence.
Every fenced CX snippet in the shipped documentation is handed to the compiler before the documentation can be published, and a page whose example does not compile does not ship. A page that names a builtin which does not exist is refused publication by a separate check reading the compiler's own builtin table. The Builtins Reference is not written at all — it is generated from the C source it documents.
The honest boundary: those checks prove that a snippet parses and that a name exists. They do not prove that the sentence around it is true. Where a page states a measured number, it says what was measured.
The site is <https://cxai.plus>, and the download's Releases page carries the release notes for each version — including, as house style, any defect that shipped in an earlier one.