-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
An idea for building and delivering $lang programs #4
Comments
I see what you're saying and why it sounds attractive. Maybe carefully designed bytecode instructions coupled with something like https://github.com/Manishearth/rust-gc to manage object lifetimes might make it feasible to translate to a limited subset of Rust. The bytecode would essentially be another layer of intermediate representation. What kind of language do you think would benefit from this approach? |
From the language perspective: From the use-case perspective: For me it's a lot less clear if the use case "embedded language" for scripting of plugins or game logic or whatever is served by this approach. A small interpreter with optional JIT (when binary size allows it) could be a better solution for that, i don't know. |
Transpiling Python to Go is a thing, of course. FWIW, at present my thoughts are that given the choices of interpreting, JIT compiling and AOT compiling, the lowest maintenance options are interpreting and AOT since there isn't a broadly maintained, compatibly-licensed JIT library around. However, I'm not convinced that transpiling to Rust makes the most sense at the outset? I understand compiling to C or Go, but Rust is opinionated. If a subset of Rust, with library support perhaps, could be shown to map reasonably from another language, and compile times improve... |
I have also thought about this topic of how one can transform a "script" (or "project" including dependencies) written However for the initial versions, a third approach much similar to (b), might be suitable: instead of embedding in For example I employ a similar technique for testing my interpreter as seen in the following snippet:
Moreover it needs zero extensions for However, as @madmalik observed in his drawbacks section, delivering such "scripts" or "projects" written in Think about the following use-case:
How compare the simple procedure described above, to a "recipe" which says:
To conclude a useful outcome from this WG would be a tutorial on how to be able to write |
@pliniker Regarding transpiling |
I realise that I conflated two issues needlessly. One is the question of optional AOT compilation (in whatever form) and the other is the reuse of rust dependency management and build infrastructure. Maybe the question of dependency management is too early and should be done when the language itself is done, idk really... |
I assume for this writeup that we've a viable strategy to compile $lang to Rust and that it yields a sizeable performance boost. Both assumptions have to be evaluated, but before that we should be sure we actually want that. ;)
I also assume the following compilation steps: $lang -> bytecode and bytecode -> Rust.
The idea is to piggyback completly on rust infrastructure. In the simplest case, a $lang program is a rust project with a
build.rs
that does either of two thinks:a.) It creates a main.rs thats a program that, wenn run, opens the actual project (maybe have a $lang-src folder in the rust project), compiles it into bytecode and then runs the bytecode. This would be the normal development workflow. The interpreter has to be compiled once and all subjequent
cargo run
commands just execute our $lang sources.b.) It opens and compiles the project into bytecode and then compiles the bytecode into a main.rs. That would be the release mode and the artifact that can be deployed is a pure rust program. It may be necessary that this binary also contain the full interpreter if runtime code execution or other dynamic features are desired.
Libraries are either written in $lang or Rust and are distributed by cargo. From the lib-user perspective both look and behave the same (since the lib code is compiled to Rust). That means that every time a library is added the development-interpreter has to be rebuild.
In essence: A standalone $lang project is not just the $lang source files, but also contains the complete description to build the runtime plus all libraries and it can create a single, self contained artefact that can be easily deployed.
Why is that useful?
Just delivering a few source files and let the end user sort out the runtime (including all nessesary libs) is not really an option. So a bundle has to be created. If we use libs written in Rust this bundle will contain plattform specific binary blobs anyway, so why not just throw the rest of the runtime into it? (thats whats many projects that are written in a dynamic language end up doing anyway)
It also reuses the excellent cargo infrastructure and makes it more natural to gradually migrate to Rust proper.
Drawbacks:
There are two use-cases that i haven't written about:
cargo install
a global interpreter with all nessesary libraries.I'd be nice if you poke some holes into this idea.
The text was updated successfully, but these errors were encountered: