Clarification added later : One of my key interests at the moment is finding ways to run untrusted code from users (or generated by LLMs) in a robust sandbox from a Python application. MicroQuickJS looked like a very strong contender on that front, so I fired up Claude Code to try that out and build some prototypes. I had Claude Code for web figure out how to run this in a bunch of different ways this morning - I hav…
Fabrice Bellard Releases MicroQuickJS
261–270 of 594 posts
Re: Fabrice Bellard Releases MicroQuickJS
#262Earlier quoted context omitted.
I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree, I think "without good reasons" is overly dismissive. Personally though, I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. Once you have written…
> I do think the authors had good reasons for their choices and have generally explained them I'm fairly certain antirez is the author of redis
Re: Fabrice Bellard Releases MicroQuickJS
#263If this had been available in 2010, Redis scripting would have been JavaScript and not Lua. Lua was chosen based on the implementation requirements, not on the language ones... (small, fast, ANSI-C). I appreciate certain ideas in Lua, and people love it, but I was never able to like Lua, because it departs from a more Algol-like syntax and semantics without good reasons, for my taste. This creates friction for newcom…
> it feels like it departs from what people know without good reasons. Lua was first released in 1993. I think that it's pretty conventional for the time, though yeah it did not follow Algol syntax but Pascal's and Ada's (which were more popular in Brazil at the time than C, which is why that is the case)! Ruby, which appeared just 2 years later, departs a lot more, arguably without good reasons either? Perl, which i…
I doubt we ever would have heard about Ruby without it's syntax decisions. From my understanding it's entire raison d'être was readability.
Re: Fabrice Bellard Releases MicroQuickJS
#264Earlier quoted context omitted.
When I first read the source for his original QuickJS implementation I was amazed to discover he created the entirety of JavaScript in a single xxx thousand line C file (more or less). That was a sort of defining moment in my personal coding; a lot of my websites and apps are now single file source wherever possible/practical.
I honestly think the single file thing is best reserved for C, given how bad the language support for modularity is. I've had the inverse experience dealing with a many thousand line "core.php" file way back in the day helping debug an expressionengine site (back in the php 5.2ish days) and it was awful . Unless you have an editor which can create short links in a hierarchical tree from semantic comments to let you o…
You can do a huge website entirely in a single file with NodeJS; you can stick re-usable templates in vars and absue multi-line strings (template literals) for all your various content and markup. If you get crafty you can embed clientside code in your 'server.js' too or take it to the next level and use C++ multi-line string literals to wrap all your JS ie- client.js, server.js and package.json in a single .cpp file
Re: Fabrice Bellard Releases MicroQuickJS
#265If this had been available in 2010, Redis scripting would have been JavaScript and not Lua. Lua was chosen based on the implementation requirements, not on the language ones... (small, fast, ANSI-C). I appreciate certain ideas in Lua, and people love it, but I was never able to like Lua, because it departs from a more Algol-like syntax and semantics without good reasons, for my taste. This creates friction for newcom…
I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree, I think "without good reasons" is overly dismissive. Personally though, I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. Once you have written…
Re: Fabrice Bellard Releases MicroQuickJS
#266If this had been available in 2010, Redis scripting would have been JavaScript and not Lua. Lua was chosen based on the implementation requirements, not on the language ones... (small, fast, ANSI-C). I appreciate certain ideas in Lua, and people love it, but I was never able to like Lua, because it departs from a more Algol-like syntax and semantics without good reasons, for my taste. This creates friction for newcom…
I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree, I think "without good reasons" is overly dismissive. Personally though, I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. Once you have written…
I'm not familiar with Lua, but I expect tco to be a feature of the compiler, not of the language. Am I wrong?
Re: Fabrice Bellard Releases MicroQuickJS
#267Earlier quoted context omitted.
This is generally the purpose of JavaScript execution environments like v8 or jsc (or quickjs although I understand not trusting that as a sandbox to the same degree). They are specifically intended for executing untrusted scripts (eg web browsers). Web assembly’s sandboxing comes from js sandboxing, since it was originally a feature of the same programs for the same reasons. Wrapping one sandbox in another is what I…
Running v8 itself as a sandbox is non-trivial, at least embedded in a Python or Node.js or similar application. The web is littered with libraries that half do that and then have a note in the README that says "do not rely on this as a secure sandbox".
It's a little less clear how you would do this from node, but the v8 embedding instructions should work https://v8.dev/docs/embed even if nodejs is already a copy of v8.
[0]: https://github.com/cloudflare/stpyv8 [1]: https://docs.pythonmonkey.io
Re: Fabrice Bellard Releases MicroQuickJS
#268Fabrice Bellard is widely considered one of the most productive and versatile programmers alive: - FFmpeg: https://bellard.org - QEMU: https://bellard.org/qemu/ - JSLinux: https://bellard.org/jslinux/ - TCC: https://bellard.org/tcc/ - QuickJS: https://bellard.org/quickjs/ Legendary.
I would not want to dismiss or diminish by any amount the incredible work he has done. It's just interesting to me that the problems he appears to pick generally take the form of "user sets up the parameters, the program runs to completion".
Re: Fabrice Bellard Releases MicroQuickJS
#269It's unfortunate that he uploaded this without notable commit history, it would be interesting to see how long it takes a programmer of his caliber to bring up a project like this. That said, judging by the license file this was based on QuickJS anyway, making it a moot comparison.
Maybe he just oneshotted it
Re: Fabrice Bellard Releases MicroQuickJS
#270Earlier quoted context omitted.
I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree, I think "without good reasons" is overly dismissive. Personally though, I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. Once you have written…
> I do think the authors had good reasons for their choices and have generally explained them I'm fairly certain antirez is the author of redis