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

301–310 of 594 posts

Re: Fabrice Bellard Releases MicroQuickJS

#301

Post by kbenson »

norir wrote: post #178
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…

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

Is it needless? It's useful specifically because he is someone influential, and someone might say "Lua was antirez's choice when making redis, and I trust and respect his engineering, so I'm going to keep Lua as a top contender for use in my project because of that" and him being clear on his choices and reasoning is useful in that respect. In any case where you think he has a responsibility to be careful what he says because of that influence, that can also be used in this case as a reason he should definitely explain his thoughts on it then and now.

Re: Fabrice Bellard Releases MicroQuickJS

#302

Post by kerkeslager »

teo_zero wrote: post #266
norir wrote: post #178

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

> Lua has a crucial feature that Javascript lacks: tail call optimization. I'm not familiar with Lua, but I expect tco to be a feature of the compiler, not of the language. Am I wrong?

I don't think you're wrong per se. This is a "correct" way of thinking of the situation, but it's not the only correct way and it's arguably not the most useful.

A more useful way to understand the situation is that a language's major implementations are more important than the language itself. If the spec of the language says something, but nobody implements it, you can't write code against the spec. And on the flip side, if the major implementations of a language implement a feature that's not in the spec, you can write code that uses that feature.

A minor historical example of this was Python dictionaries. Maybe a decade ago, the Python spec didn't specify that dictionary keys would be retrieved in insertion order, so in theory, implementations of the Python language could do something like:

  >>> abc = {}
  >>> abc['a'] = 1
  >>> abc['b'] = 2
  >>> abc['c'] = 3
  >>> abc.keys()
  dict_keys(['c', 'a', 'b'])
But the CPython implementation did return all the keys in insertion order, and very few people were using anything other than the CPython implementation, so some codebases started depending on the keys being returned in insertion order without even knowing that they were depending on it. You could say that they weren't writing Python, but that seems a bit pedantic to me.

In any case, Python later standardized that as a feature, so now the ambiguity is solved.

It's all very tricky though, because for example, I wrote some code a decade that used GCC's compare-and-swap extensions, and at least at that time, it didn't compile on Clang. I think you'd have a stronger argument there that I wasn't writing C--not because what I wrote wasn't standard C, but because the code I wrote didn't compile on the most commonly used C compiler. The better approach to communication in this case, I think, is to simply use phrases that communicate what you're doing: instead of saying "C", say "ANSI C", "GCC C", "Portable C", etc.--phrases that communicate what implementations of the language you're supporting. Saying you're writing "C" isn't wrong, it's just not communicating a very important detail: what implementations of the compiler can compile your code. I'm much more interested in effectively communicating what compilers can compile a piece of code than pedantically gatekeeping what's C and what's not.

Re: Fabrice Bellard Releases MicroQuickJS

#303

Post by DebugDruid »

hnlmorg wrote: post #233
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…

Lua only departs from norms if you’ve had a very narrow experience with other programming languages. Frankly, I welcome the fact that Redis doesn’t use JavaScript. It’s an abomination of a language. The fewer times I need to use it the better.

I think criticizing JavaScript has become a way of signaling "I'm a good programmer." Yes, good programmers ten years ago had valid reasons to criticize it. But today, attacking the efforts of skilled engineers who have improved the language (given the constraints and without breaking half of the web) seems unfair. They’ve achieved a Herculean task compared to the Python dev team, which has broken backward compatibility so many times yet failed to create a consistent language, lacking a single right way to do many things.

Re: Fabrice Bellard Releases MicroQuickJS

#304

Post by vegabook »

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…

Lua has been a wild success considering it was born in Brazil, and not some high wealth, network-effected country with all its consequent influential muscle (Ruby? Python? C? Rust? Prolog? Pascal? APL? Ocaml? Show me which one broke out that wasn't "born in the G7"). We should celebrate its plucky success which punches waaay above its adoption weight. It didn't blindly lockstep ALGOL citing "adooooption!!", but didn't indulge in revolution either, and so treads a humble path of cooperative independence of thought.

Come to think of it I don't think I can name a single mainstream language other than Lua that wasn't invented in the G7.

Re: Fabrice Bellard Releases MicroQuickJS

#305

Post by philsnow »

lucketone wrote: post #198
dbdr wrote: post #169

Earlier quoted context omitted.

That's precisely the point of using tabs for indentation: you don't need to fight over it, because it's a local display preference that does not affect the source code at all, so everyone can just configure whatever they prefer locally without affecting other people. The idea of "skins" is apparently to push that even further by abstracting the concrete syntax.

> you don't need to fight over it, because it's a local display preference This has limits. Files produced with tab=2 and others with tab=8, might have quite different result regarding nesting. (pain is still on the menu)

Do you mean that files produced with "wide" tabs might have hard newlines embedded more readily in longer lines? Or that maybe people writing with "narrow" tabs might be comfortable writing 6-deep if/else trees that wrap when somebody with their tabs set to wider opens the same file?

Re: Fabrice Bellard Releases MicroQuickJS

#306

Post by simonw »

lossolo wrote: post #294
simonw wrote: post #280

Earlier quoted context omitted.

I'm determined to normalize linking to one's own writing, provided it's relevant to the conversation.

I think you're misreading what the "normalization" problem actually is and why my comment got a lot of upvotes. You're not pushing against an arbitrary taboo where people dislike self links in principle. People already accept self links on HN when they're occasional and clearly relevant. What people are reacting to is the pattern when "my answer is a link to my site" becomes your default state, it stops reading like…

No, I'm determined to normalize it. I would like a LOT more people to have personal websites where they write at length about things, and then share links to what they have already written where it is relevant to the conversation.

I'm actively pushing back against the "don't promote your site, don't link to it, restate your content in the comments instead" thing.

I am willing to take on risk to my personal reputation and credibility in support of my goal here.

Re: Fabrice Bellard Releases MicroQuickJS

#307

Post by lioeters »

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/

I love it, I find the note interesting, educational, and adds to the discussion in context. Guess you're bound to get a few haters when you share your work in public, but I for one appreciate all your posts, comments, articles, open-source projects.

Re: Fabrice Bellard Releases MicroQuickJS

#308

Post by Uehreka »

alexdowad wrote: post #251
pizlonator wrote: post #127

Earlier quoted context omitted.

Yeah QuickJS is great. I bet MQJS will also be very popular. Quite impressive that bro is going to have two JS engines to brag about in addition to a lot of other very useful things!

> Quite impressive... Yes, quite! Monsieur Bellard is a legend of computer programming. It would be hard to think of another programmer whose body of public work is more impressive than FB. Unfortunate that he doesn't seem to write publicly about how he thinks about software. I've never seen him as a guest on any podcast either. I have long wondered who the "Charlie Gordon" who seems to collaborate with him on everyt…

> It would be hard to think of another programmer whose body of public work is more impressive than FB.

Not many, but these do come to mind: Linus Torvalds, Ken Thompson, Dennis Ritchie, Donald Knuth, Rob Pike. But yeah, it’s rarefied air up there.

Re: Fabrice Bellard Releases MicroQuickJS

#310

Post by simonw »

azakai wrote: post #289
simonw wrote: post #205

If anyone wants to try out MicroQuickJS in a browser here's a simple playground interface for executing a WebAssembly compiled version of it: https://tools.simonwillison.net/microquickjs It's a variant of my QuickJS playground here: https://tools.simonwillison.net/quickjs The QuickJS page loads 2.28 MB (675 KB transferred). The MicroQuickJS one loads 303 KB (120 KB transferred).

Looks like those sizes could be improved significantly, as the builds include names etc. I would suggest linking with emcc -O3 (and maybe even adding --closure 1 ) edit: actually the QuickJS playground looks already optimized - just the MicroQuickJS one could be improved.

Nice. Got it down from 229KB to 148KB! Thanks for the tips.

https://github.com/simonw/research/pull/5

Thats now live on https://tools.simonwillison.net/microquickjs

Post reply on HN