i just changed this in v0.2.7: the tiny compiler binary went from about 62 mb to about 16 mb by no longer embedding every target runtime inside the compiler. runtimes are downloaded and cached only when they are needed.
for memory, i did a quick test using tiny's built-in runtime.memoryStats(). these are go runtime heap stats rather than process rss.
at startup: about 8.1 mb alloc / 19.7 mb sys.
after keeping 100k object records alive, each with strings and nested arrays: about 109.3 mb alloc / 126.5 mb sys.
i should make these numbers easier to find in the readme/release notes instead of making people dig for them.
luajit is a useful reference point, but i don't think a direct comparison would be very meaningful right now. it is a much more mature runtime optimized in c, while tiny is still young, runs on top of go's runtime, and uses wasm as its jit backend, so the tradeoffs are pretty different.
thanks, the jit is still pretty early, so i would not call the language complete yet.
i started with a simple bytecode vm and built features on top of that one by one. keeping the scope practical helped a lot too, like using go for the runtime and focusing on things i actually wanted to use: packaging, http, plugins, lsp support, etc... there was also a lot of rewriting and fixing weird bugs along the way.
yeah, i think an adhoc config management tool could be a good fit for tiny. i'm not really trying to say it beats go in general. if someone already likes writing go, go is probably the better choice for a lot of projects. the point of tiny is more that you can write a normal program with a dynamic language (that has native escape hatches) and less boilerplate but still ship it as one executable like a go program.
it also has escape hatches for go/wasm and native plugins, so if part of a program needs lower-level code or an existing native library, you can call into a .dll or .so through a simple json-based plugin interface.
the niche I'm aiming for is small tools where I want a dynamic language but Go-like deployment. for example, a CLI app, an automation tool, a webview desktop app, a small HTTP server, etc... and can then be shipped as one executable without asking the user to install the runtime on their machine or manage packages