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

Porffor: A from-scratch experimental ahead-of-time JS engine

porffor.dev

Post reply on HN
Print view View original

111–120 of 148 posts

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#111

Post by syrusakbary »

tmikov wrote: post #72
syrusakbary wrote: post #8

It's awesome to see how more JS runtimes try to approach Wasm. This project reminds me to Static Hermes (the JS engine from Facebook to improve the speed of React Native projects on iOS and Android). I've spent a bit of time trying to review each, so hopefully this analysis will be useful for some readers. What are the main commonalities and differences between Static Hermes and Porffor? * They both aim for JS test26…

For the record, Static Hermes fully supports compiling JS to WASM. We get it basically for free, because it is an existing LLVM backend. See https://x.com/tmikov/status/1706138872412074204 for example. Admittedly, it is not our focus, we are focusing mainly on React Native, where WASM doesn't make sense. The most important feature of Static Hermes is our type checker, which guarantees runtime soundness. Porffor is ve…

Thanks for the correction Tzvetan! Keep up the great work in Static Hermes

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#112

Post by draw_down »

userbinator wrote: post #73

Porffor can compile to real native binaries without just packaging a runtime like existing solutions. Any language that allows generating and interpreting its own code at runtime will have the "eval problem". From some other comments here, it sounds like Porffor's solution is to simply ignore it.

[dead]

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#113

Post by syrusakbary »

concerndc1tizen wrote: post #76
syrusakbary wrote: post #18

Earlier quoted context omitted.

Since Porffor can compile itself (you can run the compiler inside of Porffor), any calls to eval could be compiled to Wasm (via executing the Porffor compiler in Porffor JS engine) and executed performantly on the same JS context * *or at least, in theory

That wouldn't work: The Wasm spec does not allow for modifying an already running program (e.g. JIT). AFAIK the only option is to include an interpreter.

You don't need to modify an already running program, you can plug new functions into an existing Wasm program via a table, and even attach variables via globals or function arguments.

I'd recommend checking the work on making SpiderMonkey emit Wasm as a backend

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#114

Post by lerpgame »

ch_sm wrote: post #7
obviouslynotme wrote: post #6

I have thought about doing this and I just can't get around the fact that you can't get much better performance in JS. The best you could probably do is transpile the JS into V8 C++ calls. The really cool optimizations come from compiling TypeScript, or something close to it. You could use types to get enormous gains. Anything without typing gets the default slow JS calls. Interfaces can get reduced to vtables or may…

Somewhat related to this idea is AssemblyScript https://www.assemblyscript.org

Yea I came here to say this, actually I was able to transpile a few typescript files from my project into assembly using GPT just for fun and it actually worked pretty well. If someone simply implements a strict typescript-like linter that is a subset of javascript and typescript that transpiles into assemblyscript, I think that would work better for AOT because then you can have more critical portions of the application in AOT and other parts that are non-critical in JIT and you get best of both worlds or something like that. making js backwards compatible and AOT sounds way too complicated.

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#115

Post by chrismorgan »

vanderZwan wrote: post #110
chrismorgan wrote: post #107

Earlier quoted context omitted.

If it’s interested in behaving as though “the ECMAScript host is a web browser”, of course it does, it’s part of the spec: https://tc39.es/ecma262/multipage/additional-ecmascript-feat... . And given how trivial it is (function() { return " " + this + " "; }), it makes a fair amount of sense to implement it even if the ECMAScript host is not a web browser, in which case it’s optional (see the top of the linked documen…

The reason I would argue that it does imply a sense of humor is that on any web browser that supports WASM, the tag itself has been deprecated and non-functional for ages. In fact, it doesn't even have an entry on MDN, only an indirect reference through String.blink() https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

, sure, but String.prototype.blink is still part of the spec, and unlike the HTML Standard, the ECMAScript specs are much more pseudocode that you largely just copy and turn into actual code as necessary, to the point that, if as an ECMAScript host it’s playing the web browser, I’d be extremely surprised (as in, “wait, what!? This is literally the weirdest technical thing I’ve seen all year, maybe this decade”) if that one method wasn’t there. When you’re implementing specs written like this, you just do it all; you don’t—you never—pick and choose based on “that thing is obsolete and no one uses it anyway”.

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#116

Post by IsTom »

g15jv2dp wrote: post #103
IsTom wrote: post #101

Earlier quoted context omitted.

I'm a little behind times on Haskell (haven't used it for some years) – there always were extensions that made it unsound, but the core language was pretty solid.

Look at the last example in there: https://counterexamples.org/polymorphic-references.html

Well, it does use unsafePerformIO. It's not particularly horrible most of the time, but in this case it obviously is.

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#117

Post by IsTom »

g15jv2dp wrote: post #87
MathMonkeyMan wrote: post #81

Earlier quoted context omitted.

Maybe OCaml, but I haven't studied it much.

I doubt it's been proved to be sound. It shows up a lot on https://counterexamples.org/ , although if I skim the issues seem to have been fixed since then.

I've run a few times into messages of the sort "you can't use these features together" before and I assume at least sometimes these were lessons that they had to learn the hard way.

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#118

Post by [deleted] »

sixbrx wrote: post #49
wk_end wrote: post #32

Earlier quoted context omitted.

So - I know this in theory, but avoided mentioning it because I couldn’t immediately think of any persuasive examples (whereas subtype polymorphism is a core, widely used, wholly unrestricted property of the language) that didn’t involve casts or any/unknown or other things that people might make excuses for. Do you have any examples off the top of your head?

Here's an example I constructed after reading the TS docs [1] about flow-based type inference and thinking "that can't be right...". It yields no warnings or errors at compile stage but gives runtime error based on a wrong flow-based type inference. The crux of it is that something can be a Bird (with "fly" function) but can also have any other members, like "swim" because of structural typing (flying is the minimum…

[deleted]

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#120

Post by eyelidlessness »

mananaysiempre wrote: post #89
cprecioso wrote: post #29

Earlier quoted context omitted.

> A TypeScript designed to aid static compilation likely would have that distinction. AssemblyScript ( https://www.assemblyscript.org/ ) is a TypeScript dialect with that distinction

It’s advertised as that, and it’s a cool project, but while it’s definitely a statically typed language that reuses TypeScript syntax, it’s not clear to me just what subset of the actual TypeScript type system is supported. That’s necessarily bad—TypeScript itself is very unclear about what its type system actually is. I just think the tagline is misleading.

Probably a better way to think about AssemblyScript is first as a DSL for WASM, and second as providing a subset of TS syntax and authoring semantics to achieve that. The type system is closer to TS than the syntax and semantics. At least that was my experience when I explored it some time back.
Post reply on HN