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)
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?).
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.
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)
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?).
What a great accomplishment! How did you manage to complete a JIT language in 2 months!?
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.