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

81–90 of 148 posts

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

#81

Post by MathMonkeyMan »

g15jv2dp wrote: post #60
munificent wrote: post #26

Earlier quoted context omitted.

I think the even bigger elephant in the room is that TypeScript's type system is unsound. You can have a function whose parameter type is annotated to be String and there's absolutely no guarantee that every call to that function will pass it a string. This isn't because of `any` either. The type system itself deliberately has holes in it. So any language that uses TypeScript type annotations to generate faster/small…

> I think the even bigger elephant in the room is that TypeScript's type system is unsound. Can you name a single language that is used for high-performance software and whose type system is sound? To speed up the process, note that none of the obvious candidates have sound type systems.

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

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

#82

Post by mike_hearn »

g15jv2dp wrote: post #60
munificent wrote: post #26

Earlier quoted context omitted.

I think the even bigger elephant in the room is that TypeScript's type system is unsound. You can have a function whose parameter type is annotated to be String and there's absolutely no guarantee that every call to that function will pass it a string. This isn't because of `any` either. The type system itself deliberately has holes in it. So any language that uses TypeScript type annotations to generate faster/small…

> I think the even bigger elephant in the room is that TypeScript's type system is unsound. Can you name a single language that is used for high-performance software and whose type system is sound? To speed up the process, note that none of the obvious candidates have sound type systems.

JVM bytecode is a "language" and is proven to be sound. The languages that compile to that language, on the other hand, are a different kettle of fish.

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

#83

Post by itsTyrion »

attractivechaos wrote: post #65
bobvarioa wrote: post #48

Earlier quoted context omitted.

Contributor to Porffor here! I actually disagree, there's quite a lot that can be improved in JS during compile time. There's been a lot of work creating static type analysis tools for JS, that can do very very thorough analysis, an example that comes to mind is [TAJS]( https://www.brics.dk/TAJS/ ) although its somewhat old.

> there's quite a lot that can be improved in JS during compile time I wonder how much performance gain you expect to achieve. For simple CPU-bounded tasks, C/Rust/etc is roughly three times as fast as v8 and Julia, which compiles full scripts and has good type analysis, is about twice as fast. There is not much room left. C/Rust/etc can be much faster with SIMD, multi-threading and fine control of memory layout but…

Honestly, I’m fine with only some speed up compared to V8, it’s already pretty fast… My issue with desktop/mobile apps using web tech (JS) is mostly the install size and RAM hunger.

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

#84

Post by canadahonk »

chillfox wrote: post #59
CharlesW wrote: post #50

What subtleties am I missing that makes "ahead-of-time JS engine" a better description than "JS-to-Wasm compiler"? (If it's mostly a framing strategy, that's cool too.)

There are already projects that does JS-to-WASM by bundling a JS interpreter. So, it's likely to make the difference to those clearer.

Yep! Also as it is technically more of an engine/runtime (sometimes) than "just" a compiler, folks in the JS space are more familiar with engine as a term :)

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

#85

Post by canadahonk »

frutiger wrote: post #71
bobvarioa wrote: post #46

Earlier quoted context omitted.

Contributor for Porffor here! I think this is a great comparison, but Porffor does technically support promises, albeit synchronously . It's a similar approach to Kiesel, https://kiesel.dev/ .

Not sure where you mean by synchronously but if you mean what I think you mean then that is not correct behaviour. This is important to ensure predicatibility. Eg. Promise.then(() => console.log(“a”)); console.log(“b”) must log [“b”, “a”] and not [“a”, “b”].

This type of test does work as expected. The "sync" means that it does not feature a full event loop (yet) so cannot easily support async I/O or some more "advanced" use cases.

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

#86

Post by g15jv2dp »

mike_hearn wrote: post #82
g15jv2dp wrote: post #60

Earlier quoted context omitted.

> I think the even bigger elephant in the room is that TypeScript's type system is unsound. Can you name a single language that is used for high-performance software and whose type system is sound? To speed up the process, note that none of the obvious candidates have sound type systems.

JVM bytecode is a "language" and is proven to be sound. The languages that compile to that language, on the other hand, are a different kettle of fish.

This is specifically about type systems. It's easy to have a sound type system when you have no type system.

Also, I'm not too familiar with JVM bytecode, but if I load i64 in two registers and then perform floating point addition on these registers, does the type system prevent me from compiling/executing the program?

Can you say more about "proven to be sound"? Are you talking about a sound type system?

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

#87

Post by g15jv2dp »

MathMonkeyMan wrote: post #81
g15jv2dp wrote: post #60

Earlier quoted context omitted.

> I think the even bigger elephant in the room is that TypeScript's type system is unsound. Can you name a single language that is used for high-performance software and whose type system is sound? To speed up the process, note that none of the obvious candidates have sound type systems.

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.

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

#88

Post by cowsandmilk »

frutiger wrote: post #71
bobvarioa wrote: post #46

Earlier quoted context omitted.

Contributor for Porffor here! I think this is a great comparison, but Porffor does technically support promises, albeit synchronously . It's a similar approach to Kiesel, https://kiesel.dev/ .

Not sure where you mean by synchronously but if you mean what I think you mean then that is not correct behaviour. This is important to ensure predicatibility. Eg. Promise.then(() => console.log(“a”)); console.log(“b”) must log [“b”, “a”] and not [“a”, “b”].

JavaScript doesn’t make the guarantee you are claiming here

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

#89

Post by mananaysiempre »

cprecioso wrote: post #29
wk_end wrote: post #14

Earlier quoted context omitted.

At least without additional extensions, TypeScript would help less than you think. It just wasn’t designed for the job. As a simple example - TypeScript doesn’t distinguish between integers and floats; they’re all just numbers. So all array accesses need casting. A TypeScript designed to aid static compilation likely would have that distinction. But the big elephant in the room is TypeScript’s structural subtyping. T…

> 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.
Post reply on HN