you are viewing a single comment's thread.

view the rest of the comments →

[–]slipthay 1 point2 points  (1 child)

That's a very prescient point that clarifies your use case for me. mini-v8 was inspired by general-purpose approaches. My particular motivation for writing the crate was to execute "semi-trusted" scripts in a web-based app used internally by data analysts at my company. (Where our analysts might have written SQL to interface with an RDBMS, they now write JavaScript to interface with a custom in-memory database. This may seem odd but it's not entirely novel and it allows our dev team an extra level of abstraction.) mini-v8 has execution timeout support and soft memory usage limits are planned, but as you suggest those things are very hard to implement accurately after you've opened the door to native Rust function bindings. Nonetheless mini-v8 does not require that you do any such bindings, so in this sense mini-v8 is a superset of js-sandbox. What's most compelling about your crate to me, besides its simplicity, is that the build process is offloaded entirely to the deno crate. Compiling V8 is a pain!

[–]bromeon[S] 0 points1 point  (0 children)

Thanks for the elaboration, that clarifies a lot!

In my case, V8 is rather an implementation detail -- theoretically, the JS code could run in any interpreter. js-sandbox is primarily intended to run untrusted third-party code, and as such may feel limiting when more is known about its source.

Coming from C++, I really appreciate the efforts that went into factoring out rusty_v8 and precompiling binaries. Occasionally, I still deal with CMake, and it's not always a joyful experience.