Beware the creator of this language doesn't want your contributions. He'll just take some of the code you wrote and pass it off as his own so no one else gets their name on the project.
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.
What is the motivation and use case in coding agents era for this project?
Dont get me wrong, this question echoes in my head for some time now. Especially with supply chain attacks and open source libraries being entirely written by AI, whats my motivation to use open source libs? Previously it was time-saving, now this incentive vanish since its not me spending more time (but agent)
You make so many outlandish claims and outrageous statements - Oss libraries being entirely ai, you can trivially replace any Oss library with agent output, etc. It really distracts from your core question (which has a premise that doesn't seem reasonable)
Its a generalizatiom but this is a direction Im seeing. I maintain OSS project logdy.dev. Until last year around this time I saw a steady influx of github stars every week (not huge but steady enough to project next few weeks). Since then, the traction pretty much stopped. So my thinking is - in coding agents era people dont need to format their local logs since agents take care of the dev mostly. If I were to start this project again, I wouldnt do it right now since the problem wouldnt be worth solving. The economics moved. This is just my example but I guess similar things are happening out there. So, the question remains, is there a use case for niche oss projects anymore? (By niche I mean something thats not mainstream)
The author should call out size of binaries (compiled and generated), the interpreter as well since that's teh selling point. if it's tiny from memory requiremetns , shoudl also call out the same, potentially benchmarking against similar (luajit?).
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.
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
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.
Beware the creator of this language doesn't want your contributions. He'll just take some of the code you wrote and pass it off as his own so no one else gets their name on the project.
What a great accomplishment! How did you manage to complete a JIT language in 2 months!?
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.
What is the motivation and use case in coding agents era for this project? Dont get me wrong, this question echoes in my head for some time now. Especially with supply chain attacks and open source libraries being entirely written by AI, whats my motivation to use open source libs? Previously it was time-saving, now this incentive vanish since its not me spending more time (but agent)
You make so many outlandish claims and outrageous statements - Oss libraries being entirely ai, you can trivially replace any Oss library with agent output, etc. It really distracts from your core question (which has a premise that doesn't seem reasonable)
Its a generalizatiom but this is a direction Im seeing. I maintain OSS project logdy.dev. Until last year around this time I saw a steady influx of github stars every week (not huge but steady enough to project next few weeks). Since then, the traction pretty much stopped. So my thinking is - in coding agents era people dont need to format their local logs since agents take care of the dev mostly. If I were to start this project again, I wouldnt do it right now since the problem wouldnt be worth solving. The economics moved. This is just my example but I guess similar things are happening out there. So, the question remains, is there a use case for niche oss projects anymore? (By niche I mean something thats not mainstream)
The author should call out size of binaries (compiled and generated), the interpreter as well since that's teh selling point. if it's tiny from memory requiremetns , shoudl also call out the same, potentially benchmarking against similar (luajit?).
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.
What's the use-case here? Where and why would one use Tiny instead of just using Go (or something else like Python)?
Faster development with an interpreted dynamic language with performance boosts from the JIT and inline Go.
You can do similar things in other languages but not AFAIK as a built in feature. You can have in line C innTCL
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
this is interesting, i'm wondering if it can beat just installing go though.
I think it'd be interesting to build a adhoc config mgmt system w/ this and use it as a high level scripting language.
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.