The zkl FAQ

Q: How do I create and run a non trivial program?
A1: Use your favorite text editor to write your program source code.
The preferred extension is ".zkl" but that is your choice.
From the command line: zkl myprogram
A2: Create your program.
Compile it: zkl -C myprogram -o . // write to myprogram.zsc
Run it: zkl myprogram // .zsc is matched first or use the extension to force
Q: That is still only one file.
A3: OK, OK. Consider Frame-O-Matic: Eight source files (over 3,000 lines), four images (GIFs) and a text file packaged into one wad (zsc). Import statements (in the source) hook all the pieces together to make a "tree", starting from a "main" file (ie main imports some things, which import other things (or recursively import already imported things), etc). The program can then be run any of three ways: source (slow as each file is compiled at runtime), a collection of compiled files (or a mix of source and compiled), or as one package (created via the --package compiler option, which traces the tree, starting at the main file, and does a whole program compilation/link).

Q: How do I debug my program? An IDE?
A: With print statements or using the _debug_ keyword. It sucks but the debugger isn't a source level debugger so it isn't much use to anyone.

No IDE or Eclipse/etc plug in.

Q: What does this run on?
A: Windows 10 and Unix. Tested on 64 bit Windows 10 (VMWare), Unix compiled with clang (Ubuntu native and FreeBSD, PC-BSD running under VMWare).
A: A port requires good preemptive thread support (eg native Windows threads or pThreads), some atomic operation support (atomically testing/exchange/setting/increment ints) and a good C compiler. Minix3 has most of that but the pthreads library is poor so the port fails.

Q: What CPU?
A: Intel/AMD.

Q: What is a good box?
A: I use a Intel I7 with 4 cores/4 threads and 16g of RAM running Linux Mint. Very nice. I run Windows 10, PC-BSD & FreeBSD in VMWare 4 core/4g VMs. The VM are very much slower (for reasons I don't understand).

Q: Can zkl be used for CGI scripts?
A: Yes (I use it with Apache). If you compile your CGI scripts with
   zkl --#! C:/Bin/zkl.exe -c ...
the .zsc file will have a "#!" line in it that the Apache server will look at. Otherwise, you need to make sure the server path includes zkl.exe. Of course, you also use .zkl files. If you use a "shebang" line in your source, you can compile it with
   zkl --#! . -c ...
which tells the compiler to look for the shebang line in the first two lines of the source code (so emacs users can still use -*-c-*-).

There is no mod_zkl.

Q: How stable is zkl?
A: Pretty good (depending on the day, I'm still making lots of changes). There are very likely still race conditions in the VM and maybe a dead lock in the garbage collector.

Q: What is memory usage like?
A: It is a pig, even with the garbage collector screwed down tight. GC costs about 20% in speed. A typical memory footprint seems to be around 10meg (32 bit windows).

Q: Unicode?
A: Very, extremely limited. Strings are 8 bit clean (but not binary clean; zero is special), supports "\uXXXX" to convert Unicode to UTF-8, can verify that a string is valid UTF-8 and calculate the length of a UTF-8 string (Unicode characters vs bytes). But the none of the string support methods are UTF-8 aware.

Q: Talk about threads.
A: zkl uses OS/preemptive threads. Not green, not cooperative, not light weight; just heavy metal OS threads (if you like cooperative threads, fibers are available). The VM is thread safe, GC is a thread, the compiler is threaded, there is no “global interpreter lock”, and many objects (such as lists, dictionaries and strings) are thread safe. Things are not all roses however, class variables are not thread safe and require manual locking. Objects are provided for this (locks, pipes, etc). Any class, function or method can become a thread; just call the “launch" or "future" method (see the manual) and a thread is created. No drama, no trauma, it just happens. As an example, the “test suite overlord” threads the tests (using one pipe, one atomic integer, and an atomic waiter in a "boss thread runs a bunch of worker threads" model); it uses 150+ threads. Swamps all cores on my 8 way machine.
Does it scale? Yes, but the OS can be a real party pooper and the overhead of OS thread management means lots of little threads makes things slower. I have seen near linear speed ups with long lived [compute] threads [that don't exceed the number of cores].