Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fabrice Bellard Releases MicroQuickJS

github.com

Post reply on HN
Print view View original

171–180 of 594 posts

Re: Fabrice Bellard Releases MicroQuickJS

#171

Post by rwmj »

brabel wrote: post #157
antirez wrote: post #111

If 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…

We had a lot problems embedding Ruby in a multithreaded C program as the garbage collector tries to scan memory between the threads (more details here: https://gitlab.com/nbdkit/nbdkit/-/commit/7364cbaae809b5ffb6... )

Perl, Python, OCaml, Lua and Rust were all fine (Rust wasn't around in 2010 of course).

Re: Fabrice Bellard Releases MicroQuickJS

#172

Post by halfmatthalfcat »

simonw wrote: post #167
halfmatthalfcat wrote: post #78

Earlier quoted context omitted.

I downvoted because I'm tired of people regurgitating how they've done this or that with whatever LLM of the week on seemingly every technical post. If you care that much, write a blog post and post that, we don't need low effort LLM show and tell all day everyday.

Here you go: https://simonwillison.net/2025/Dec/23/microquickjs/

No I mean post it as an HN post and if anybody cares to see it, they'll upvote that and comment in there. That, instead of pigging backing on other posts to get visibility.

Re: Fabrice Bellard Releases MicroQuickJS

#173

Post by simonw »

MobiusHorizons wrote: post #116
simonw wrote: post #17

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…

What is the purpose of compiling this to web assembly? What web assembly runtimes are there where there is not already an easily accessible (substantially faster) js execution environment? I know wasmtime exists and is not tied to a js execution engine like basically every other web assembly implementation, but the uses of wasmtime are not restricted from dependencies like v8 or jsc. Usually web assembly is used for…

I want to build features - both client- and server-side - where users can provide JavaScript code that I then execute safely.

Just having a WebAssembly engine available isn't enough for this - something has to take that user-provided string of JavaScript and execute it within a safe sandbox.

Generally that means you need a JavaScript interpreter that has itself been compiled to WebAssembly. I've experimented with QuickJS itself for that in the past - demo here: https://tools.simonwillison.net/quickjs - but MicroQuickJS may be interesting as a smaller alternative.

If there's a better option than that I'd love to hear about it!

Re: Fabrice Bellard Releases MicroQuickJS

#174

Post by brabel »

ronsor wrote: post #71
simonw wrote: post #64

Earlier quoted context omitted.

He's also built a closed-source LLM inference engine, which he's been maintaining since the GPT-2 days: https://bellard.org/ts_server/ and https://textsynth.com/

I used to play around with Textsynth, but not being OSS killed the appeal for me once llama.cpp came around.

I thought Bellard might be behind even llama.cpp (that would be completely expected for Bellard) but it's actually another great who's done that: Georgi Gerganov: https://github.com/ggerganov

Re: Fabrice Bellard Releases MicroQuickJS

#175

Post by rasz »

ddtaylor wrote: post #50

Fabrice 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.

Funny how people know Fabrice for all the software stuff but none of the hardware antics:

played with implementing analog modem DSP in software in 1999 (linmodem is ~50-80% there, sadly never finished)

probably leading to

played with implementing SDR (again DSP) using VGA output to transmit DVB-T/NTSC/PAL in 2005

probably leading to

Amarisoft SDR 5G base station, commercial product started in 2012 - his current job https://www.amarisoft.com/company/about-us

Re: Fabrice Bellard Releases MicroQuickJS

#176

Post by nine_k »

brabel wrote: post #163
nine_k wrote: post #149

Earlier quoted context omitted.

Not "never exploit"; Reason and BuckleScript are examples of different "language skins" for OCaml. The problem with "skins" is that they create variety where people strive for uniformity to lower the cognitive load. OTOH transparent switching between skins (about as easy as changing the tab sizes) would alleviate that.

> OTOH transparent switching between skins (about as easy as changing the tab sizes) would alleviate that. That's one of my hopes for the future of the industry: people will be able to just choose the code style and even syntax family (which you're calling skin) they prefer when editing code, and it will be saved in whatever is the "default" for the language (or even something like the Unison Language: store the AST…

Also consider translation to non-English languages, including different writing and syntax systems (e.g. Arabic or Japanese).

Some languages have tools for more or less straightforward skinning.

Clojure to Tamil: https://github.com/echeran/clj-thamil/blob/master/src/clj_th...

C++ to distorted Russian: https://sizeof.livejournal.com/23169.html

Re: Fabrice Bellard Releases MicroQuickJS

#177

Post by spacechild1 »

antirez wrote: post #111

If 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 is a pretty old language. In 1993 the world had not really settled on C style syntax. Compared to Perl or Tcl, Lua's syntax seems rather conventional.

Some design decisions might be a bit unusual, but overall the language feels very consistent and predictable. JS is a mess in comparison.

> because it departs from a more Algol-like syntax

Huh? Lua's syntax is actually very Algol-like since it uses keywords to delimit blocks (e.g. if ... then ... end)

Re: Fabrice Bellard Releases MicroQuickJS

#178

Post by norir »

antirez wrote: post #111

If 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 enough Lua, your mind easily switches in and out of Lua mode. Javascript, on the other hand, is filled with poor semantic decisions which for me, cancel out any benefits from syntactic familiarity.

More importantly, Lua has a crucial feature that Javascript lacks: tail call optimization. There are programs that I can easily write in Lua, in spite of its syntactic verbosity, that I cannot write in Javascript because of this limitation. Perhaps this particular JS implementation has tco, but I doubt it reading the release notes.

I have learned as much from Lua as I have Forth (SmallTalk doesn't interest me) and my programming skill has increased significantly since I switched to it as my primary language. Lua is the only lightweight language that I am aware of with TCO. In my programs, I have banned the use of loops. This is a liberation that is not possible in JS or even c, where TCO cannot be relied upon.

In particular, Lua is an exceptional language for writing compilers. Compilers are inherently recursive and thus languages lacking TCO are a poor fit (even if people have been valiantly forcing that square peg through a round hole for all this time).

Having said all that, perhaps as a scripting language for Redis, JS is a better fit. For me though Lua is clearly better than JS on many different dimensions and I don't appreciate the needless denigration of Lua, especially from someone as influential as you.

Re: Fabrice Bellard Releases MicroQuickJS

#179

Post by groundzeros2015 »

benterix wrote: post #119
groundzeros2015 wrote: post #75

Earlier 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.

Because he choose the hardest path. Difficult problems, no shortcuts, ambitious, taking time to complete. Our environment in general is the opposite of that.

We spend a lot of time doing busy work that's part of the process but doesn't actually move the needle. We write a lot of code that manages abstractions, but doesn't do a lot. All of this busy work feels like progress, but it's avoiding the hard work of actually writing working code.

We underestimate how inefficient working in teams is compared with individuals. We don't value skill and experience and how someone who understands a problem well can be orders of magnitude more productive.

Re: Fabrice Bellard Releases MicroQuickJS

#180

Post by krackers »

idle_zealot wrote: post #150
IshKebab wrote: post #137

Earlier quoted context omitted.

Not to mention the 1-based indexing sin. JavaScript has a lot of WTFs but they got that right at least.

Does it count as 0-indexing when your 0 is a floating point number?

Actually in JS array indexing is same as property indexing right? So it's actually looking up the string '0', as in arr['0']
Post reply on HN