Not sure about the impact of these, I guess it depends on the context where this engine is used. But there seems to be already exploits for the engine:
Fabrice Bellard Releases MicroQuickJS
481–490 of 594 posts
Re: Fabrice Bellard Releases MicroQuickJS
#482As a long-time Espruino user I was immediately interested.
At first glance Espruino has broader coverage including quite a bit of ES6 and even up to parts of ES2020. (https://www.espruino.com/Features). And obviously has a ton of libraries and support for a wide range of hardware.
For a laugh, and to further annoy the people annoyed by @simonw's experiments, I got Cursor to butcher it and run as a REPL on an ESP32-S3 over USB-Serial using ESP-IDF.
Blink is now running so my work here is done :-)
led.init(48)
function blink() {
led.rgb(0, 0, 255)
setTimeout(function() {
led.off();
setTimeout(blink, 500)
}, 500)
}
blink()Re: Fabrice Bellard Releases MicroQuickJS
#483Earlier quoted context omitted.
Not to mention the 1-based indexing sin. JavaScript has a lot of WTFs but they got that right at least.
There's nothing wrong with 1-based indexing. The only reason it seems wrong to you is because you're familiar with 0-based, not because it's inherently worse.
I'll refer you to Dijkstra's "Why numbering should start at zero": https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...
Re: Fabrice Bellard Releases MicroQuickJS
#484Fabrice 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.
Don't forget his LLM based text compression software that won awards. Guy is a genius. I hope he tries Rust someday
Link please?
Re: Fabrice Bellard Releases MicroQuickJS
#485If 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…
Lua syntax is pretty good for DSL (domain specific language) cases / configuration definitions.
For example Premake[1] uses Lua as it is - without custom syntax parser but with set of domain specific functions.
This is pure Lua:
workspace "MyWorkspace"
configurations { "Debug", "Release" }
project "MyProject"
kind "ConsoleApp"
language "C++"
files { "**.h", "**.cpp" }
filter { "configurations:Debug" }
defines { "DEBUG" }
symbols "On"
filter { "configurations:Release" }
defines { "NDEBUG" }
optimize "On"
Re: Fabrice Bellard Releases MicroQuickJS
#486Earlier quoted context omitted.
Lots of comments talking about how existing browsers can already do this, but the big benefit that current browsers can't give you is the sheer level of speed and efficiency that a highly restricted "lite web" browser could achieve, especially if the restrictions are made with efficiency in mind. The embedded use case is obvious, but it'd also be excellent for things like documentation — with such a browser you could…
Is MQJS faster or lighter than other engines though? It says the engine itself takes very little memory, but that doesn't say how it performs running all that bloated JS out there. Well also has "quick" in the name.
How it performs with existing JS doesn’t really matter in the context of my post, though.
For a “lite web” browser that’s built for a thin, select slice of the web stack (HTML/CSS/JS), dragging around the heft of a full fat JS engine like V8 is extreme overkill, because it’s not going to be running things like React but instead enabling moderate use of light enhancing scripts — something like a circa-2002 website would skew toward the heavy side of what one might expect for a “lite web” site.
The JS engine for such a browser could be trimmed down and aggressively optimized, likely even beyond what has been achieved with MQJS and similar engines, especially if one is willing to toss out legacy compatibility and not keep themselves beholden to every design decision of standard JS.
Re: Fabrice Bellard Releases MicroQuickJS
#487Earlier quoted context omitted.
Pascal. Modula-2. BASIC. Hell, Logo. Lately, yes, Julia and R. Lots of systems I grew up with were 1-indexed and there's nothing wrong with it. In the context of history, C is the anomaly. I learned the Wirth languages first (and then later did a lot of programming in MOO, a prototype OO 1-indexed scripting language). Because of that early experience I still slip up and make off by 1 errors occasionally w/ 0 indexed…
As I understand it Julia changed course and is attempting to support arbitrary index ranges, a feature which Fortran enjoys. (I'm not clear on the details as I don't use either of them.)
Let’s hope that they don’t also replicate ISO Fortran’s design flaws with lower array bounds, which contain enough pitfalls and portability problems that I don’t recommend their use.
Re: Fabrice Bellard Releases MicroQuickJS
#488Earlier quoted context omitted.
Since you’re on the topic, what ever happened to the multi threading stuff you were doing on JSC? Did it stop when you left Apple? Is the code still in JSC or did it get taken out?
Which multi-threading are you talking about?
Re: Fabrice Bellard Releases MicroQuickJS
#489Earlier quoted context omitted.
For all the praise he gets here, few seem interested in his methods: writing complete programs, based on robust computer science, with minimal dependencies and tooling.
He's one of my programming heroes but that's based purely on the sheer volume of high quality output he has. Can you elaborate a little about the methods you mention and how you analysed them?
Sure. You’ll notice no libraries, no CI, no issue tracker, written in C, no landing page, no dashboard.
So much of the discussion here is about professional practice around software. You can become an expert in this stuff without actually ever learning to write code. We need to remember that most of these tools are a cost that only benefits for managing collaboration between teams. The smaller the team the less stuff you need.
I also have insights from reading his C style but they may be of less interest.
I think it’s also impressive that he identifies a big and interesting problem to go after that’s usually impactful.
Re: Fabrice Bellard Releases MicroQuickJS
#490Earlier 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…
Formally JavaScript is specified as having TCO as of ES6, although for unfortunate and painful reasons this is spec fiction - Safari implements it, but Firefox and Chrome do not. Neither did QuickJS last I checked and I don't think this does either.
ES is now ES2025, not ES6/2015. There are still platforms that don't even fully implement enough to shim out ES5 completely, let alone ES6+. Portions of ES6 require buy in from the hosting/runtime environment that aren't even practical for some environments... so I feel the statement itself is kind of ignorant.