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

101–110 of 148 posts

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

#101

Post by IsTom »

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.

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.

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

#102

Post by tempodox »

giancarlostoro wrote: post #100

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…

That sounds like we could finally get rid of the worst programming language to ever reach as widespread adoption as JS has today. I can't wait!

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

#103

Post by g15jv2dp »

IsTom wrote: post #101
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.

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

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

#104

Post by [deleted] »

nequo wrote: post #95
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.

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

[deleted]

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

#105

Post by spankalee »

canadahonk wrote: post #85
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”].

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.

There's a WASI async functions proposal I think? Are you looking at supporting that so you don't have to bring your own event loop?

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

#106

Post by munificent »

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.

Java, C#, Scala, Haskell, and Dart are all sound as far as I know.

Soundness in all of those languages involves a mixture of compile-time and runtime checks. Most of the safety comes from the static checking, but there are a few places where the compiler defers checking to runtime and inserts checks to ensure that it's not possible to have an expression of type T successfully evaluate to a value that isn't an T.

TypeScript doesn't insert any runtime checks in the places where there are holes in the static checker, so it isn't sound. If it wasn't running on top of a JavaScript VM which is dynamically typed and inserts checks everywhere, it would be entirely possible to segfault, violate memory safety, etc.

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

#107

Post by chrismorgan »

vanderZwan wrote: post #90

I unironically appreciate that it supports String.blink. It's always a good sign if the developer has a sense of humor and playfulness.

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 document). I wouldn’t expect it to have any association with “a sense of humor or playfulness” whatsoever.

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

#108

Post by jitl »

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…

In my mind, the big room for improvement is eliminating the cost to call from JS into other native languages. In node/V8 you pay a memcopy when you pass or return a string from C++ land. If an ahead of time compiler for JS can use escape analysis or other lifetime analysis for string or byte array data, you could make I/0 or at least writes from JavaScript to, for example, sqlite, about twice as fast.

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

#109

Post by jitl »

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

Yes, it does. Promise continuations always run in the micro task queue per the standard. I guess if someone mutates the promise prototype it’s not guaranteed, but the spec does guarantee this order

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

#110

Post by vanderZwan »

chrismorgan wrote: post #107
vanderZwan wrote: post #90

I unironically appreciate that it supports String.blink. It's always a good sign if the developer has a sense of humor and playfulness.

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

Post reply on HN