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

561–570 of 594 posts

Re: Fabrice Bellard Releases MicroQuickJS

#561

Post by teo_zero »

NuclearPM wrote: post #467
teo_zero wrote: post #325

Earlier quoted context omitted.

Thank you for the precise answer. I still think that the language property (or requirement, or behavior as seen by within the language itself) that we're talking about in this case is "unbounded nested calls" and that the language specs doesn't (shouldn't) assume that such property will be satisfied in a specific way, e.g. switching the call to a branch, as TCO usually means.

Why do you think that?

Because that's a description of the intended behavior, and I reason about a language as an abstraction that allows one to express an expected behavior ignoring the implementation details.

I know it's not universal: some languages in their infancy lack a formalization and are defined by their reference implentation. But a more theoretical approach has allowed languages like C to strive for years.

Re: Fabrice Bellard Releases MicroQuickJS

#562

Post by coryrc »

vbezhenar wrote: post #360
coryrc wrote: post #74

Earlier quoted context omitted.

You can just use HTML4 if you want, it's already supported and standardized. Markdown is very much not.

HTML4 + CSS (2?) + JavaScript is already huge platform, very much not trivial to implement. Like you can already do something like that with niche browsers like links, but it's obviously not working, so something else is needed...

Markdown doesn't do the latter two, so that's not comparable in the slightest.

Re: Fabrice Bellard Releases MicroQuickJS

#563

Post by zellyn »

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…

I’m horribly biased but I think it’s a combination of: (1) knee-jerk reaction to similar-looking but low-value comments, and (2) most people not having played around with LLM coding agents and messed around with their own agents enough to immediately jump to excitement at simple, safe sandboxing primitives for that purpose.

And +1000 on linking to your own (or any other well-written) blog.

Re: Fabrice Bellard Releases MicroQuickJS

#565

Post by mbac32768 »

leptons wrote: post #378
hnlmorg wrote: post #233

Earlier quoted context omitted.

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.

Every programming language is an abomination depending on the perspective.

To paraphrase Bjarne Stroustrup, there are two kinds of programming languages. There are abominations and then there are the ones nobody uses.

Re: Fabrice Bellard Releases MicroQuickJS

#566

Post by vkdelta »

yoan9224 wrote: post #532

bellard is basically proof that the "10x engineer" exists. ffmpeg, qemu, quickjs, and now this... all from one person. the fact that he can optimize a js engine down to 10kb of ram is wild. would love to see this on esp32 boards

What use-cases do you think it would help on esp32?

Re: Fabrice Bellard Releases MicroQuickJS

#567

Post by strbean »

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…

Curious if you have a specific use case for sandboxed JS that you would share?

Re: Fabrice Bellard Releases MicroQuickJS

#568

Post by noduerme »

aapoalas wrote: post #453
noduerme wrote: post #389

>> Arrays cannot have holes. Writing an element after the end is not allowed: a = [] a[0] = 1; // OK to extend the array length a[10] = 2; // TypeError If you need an array like object with holes, use a normal object instead Guess I'm a bit fuzzy on this, I wouldn't use numeric keys to populate a "sparse array", but why would it be a problem to just treat it as an iterable with missing values undefined? Something to…

Guidance towards correct usage: eg. If you allow `a[10] = 2` and just make the Array dense, the user might not even realise the difference and will assume it's sparse. Next they perform `a[2636173747] = 3` and clog up the entire VM memory or just plain crash it from OOM. Since it's likely that the small indexes appear in testing and the large indexes appear in production, it is better to make the misunderstanding an…

So it's guidance. Does V8 just treat those as an object?

Re: Fabrice Bellard Releases MicroQuickJS

#569

Post by aapoalas »

keepamovin wrote: post #541
nektro wrote: post #504

Earlier quoted context omitted.

you might be interested in the future of https://porffor.dev/

Oh, this is excellent! I'm so happy with this. This is EXCELLENT! and what a beautiful website. Is this your project? So cool. Where did the name come from? I am so stoked and glad that we are going to have a JS to native binary compiler. The best thing ever! I was going to set up an AI automation to run on this against the autotests, but as I got started, I felt - why not just create a new language where I can pick…

This is Oliver Medhurst' project: https://goose.icu/

It has stable funding and a full-time development team of 1.

Re: Fabrice Bellard Releases MicroQuickJS

#570

Post by Calavar »

teo_zero wrote: post #322
naasking wrote: post #276

Earlier quoted context omitted.

If the language spec requires TCO, I think you can reasonably call it part of the language.

It wouldn't be the first time the specs have gone too far and beyond their perimeter. C's "register" variables used to have the same issue, and even "inline" has been downgraded to a mere hint for the compiler (which can ignore it and still be a C compiler).

"inline" was always just a hint
Post reply on HN