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

91–100 of 148 posts

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

#91

Post by mananaysiempre »

pjmlp wrote: post #28
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…

Such Typescript already exists, Static Typescript, https://makecode.com/language Microsoft's AOT compiler for MakeCode, via C++.

The 2019 paper[1] says: “STS primitive types are treated according to JavaScript semantics. In particulars, all numbers are logically IEEE 64-bit floating point, but 31-bit signed tagged integers are used where possible for performance. Implementation of operators, like addition or comparison, branch on the dynamic types of values to follow JavaScript semantics[.]”

[1]: https://www.microsoft.com/en-us/research/publication/static-...

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

#92

Post by mike_hearn »

g15jv2dp wrote: post #86
mike_hearn wrote: post #82

Earlier quoted context omitted.

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?

It does have a type system.

https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-2.h...

JVM is a stack not register machine and yes the type system will prevent that from running. It will fail verification.

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

#93

Post by mst »

itsTyrion wrote: post #83
attractivechaos wrote: post #65

Earlier quoted context omitted.

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

[raises hand] I'd be fine with no speedup at all if I can get more reasonable RAM usage and an easily linkable .so out of the deal.

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

#94

Post by meiraleal »

pandemic_region wrote: post #77
pityJuke wrote: post #36

Earlier quoted context omitted.

Also funded the Ladybird browser recently. Seems to like his web.

Not familiar with this stuff at all, is Porffor a js engine that Ladybird could end up using? Or are they still writing their own?

If that happens I would thank defunkt so much. Great way to spend money.

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

#95

Post by nequo »

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.

Scala 3 has aimed to get sound but I’m not sure how far they got?

https://www.scala-lang.org/api/3.x/docs/blog/2016/02/17/scal...

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

#96

Post by fwip »

cowsandmilk wrote: post #88
frutiger wrote: post #71

Earlier quoted context omitted.

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

What do you mean? Does JavaScript allow the `then` of a promise to execute before the contents of the promise?

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

#97

Post by simlevesque »

pandemic_region wrote: post #77
pityJuke wrote: post #36

Earlier quoted context omitted.

Also funded the Ladybird browser recently. Seems to like his web.

Not familiar with this stuff at all, is Porffor a js engine that Ladybird could end up using? Or are they still writing their own?

You'd have to wait before using any website using js. The AOT introduces a delay. Not sure it's achievable.

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

#98

Post by skitter »

g15jv2dp wrote: post #86
mike_hearn wrote: post #82

Earlier quoted context omitted.

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?

The type checker is specified in Prolog and rejects the above scenario:

    instructionIsTypeSafe(fadd, Environment, _Offset, NextStackFrame, ExceptionStackFrame) :- 
        validTypeTransition(Environment, [float, float], float, StackFrame, NextStackFrame),
        exceptionStackFrame(StackFrame, ExceptionStackFrame).
Fun fact: Said type system has a 'top' type that is both the top type of the type system as well as the top half of a long or double, as those two actually take two values while everything else, including references, is only one value. Made some sense when everything was 32 bit, less so today.

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

#99

Post by giancarlostoro »

pandemic_region wrote: post #77
pityJuke wrote: post #36

Earlier quoted context omitted.

Also funded the Ladybird browser recently. Seems to like his web.

Not familiar with this stuff at all, is Porffor a js engine that Ladybird could end up using? Or are they still writing their own?

Porffor compiles the JS to WASM, so it would be kind of a waste. Though there might be no reason the two projects cannot share some logic, like parsing the JS and such. I kind of doubt this is why its being funded. It sounds like a useful project.

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

#100

Post by giancarlostoro »

The most interesting bit about Porffor in my eyes is it lets JavaScript compete with something like Blazor (or allows JS to stand its ground), which kind of makes using any JS in your project redundant, since all your front-end logic can be done in C#. The reason I say this is, because obviously, there are JS devs, but if WASM tooling in other languages grows it will make JS redundant or feel incomplete / outcompeted.

I wont be surprised to see a SPA framework that uses Porffor once it is more mature, or even the major ones using it as part of their tooling.

WASM is the next step after SPA's essentially.

If you have never touched Blazor, I recommend you check it out via youtube video if you don't do any C#, it is impressive. Kudos to Microsoft for it. I have had 0 need or use for JavaScript since using it.

Post reply on HN