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

131–140 of 148 posts

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

#131

Post by saghm »

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.

The tagline on the site seems to be " TypeScript-like language for WebAssembly", which seems pretty clear to me that it's not pretending to be a strict subset or anything.

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

#132

Post by saghm »

oxidant wrote: post #68
sixbrx wrote: post #49

Earlier quoted context omitted.

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…

This narrowing is probably not the best. I'm not sure why the TS docs suggest this approach. You should really check the type of the key to be safer, though it's still not perfect. if (typeof animal.swim === 'function') {....}

Compilers don't really have the option of just avoiding non-idiomatic code, though. If the goal is to compile TypeScript ahead of time, the only options are to allow it or to break compatibility, and breaking compatibility makes using ahead-of-time TypeScript instead of some native language that already exists much less compelling.

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

#133

Post by kcrwfrd_ »

wk_end wrote: post #32
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…

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?

  const foo: string[] = ['foo']
  
  // inferred as string
  // though it is undefined
  const bar = foo[1]

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

#134

Post by saghm »

munificent wrote: post #106
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.

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

I can't speak for the others, but Java allows assigning arrays of subtypes to variables declared as an array of a supertype, which isn't sound:

    class A {}
    class B1 extends A {}
    class B2 extends A {}
    
    A[] arr = new B1[1];
    arr[0] = new B2();
In the above example only way that assigning an array of `B1` to a variable typed as an array of `A` is if only valid `B1` objects are ever put into it, at which point there's no reason not to just have the variable typed as a `B1` array. It still will compile fine though!

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

#135

Post by astrobe_ »

apgwoz wrote: post #128
canadahonk wrote: post #52

Earlier quoted context omitted.

Exactly. The versioning system is definitely unique and controversial, but I think it fits for a fast moving project like this, so I don't have to really consider versioning which could slow development. When it becomes more stable, I'll likely move to a more traditional semver scheme from 1.0.

What happens if there’s a regression in coverage, maybe due to a large sweeping change, and you go from 0.40 -> 0.35 ?

There's the commit hash. Basically the "version number" is the commit hash, the human-generated (version) numbers added to it are merely progress indicators, which might be randomly useful. But for a project that has 1 branch, 0 tags and nearly 2000 commits, that's not really important.

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

#136

Post by katspaugh »

simlevesque wrote: post #9
awesomekling wrote: post #5

Oliver (the main developer) just announced that they’re going to work full time on Porffor: https://x.com/canadahonk/status/1818347311417938237

Financed by defunkt[1], GitHub cofounder and ex CEO, for an undisclosed future project. [1] https://news.ycombinator.com/user?id=defunkt

Given that defunkt's current project is a game engine/IDE, makes sense he's interested in an ultra-fast compiler for a popular language that builds compact sub-MB native executables...

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

#137

Post by vanderZwan »

chrismorgan wrote: post #115
vanderZwan wrote: post #110

Earlier quoted context omitted.

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…

Ok, ok, fine. But I still find it humorous to see it pop up in the list of supported JS functions

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

#138

Post by xyproto »

Promising, but a few rough edges.

> 1+1

2

> help

Uncaught ReferenceError: help is not defined at exports. [as main] (file:///opt/homebrew/lib/node_modules/porffor/compiler/wrap.js:494:19) at REPLServer.run (file:///opt/homebrew/lib/node_modules/porffor/runner/repl.js:98:27) at bound (node:domain:432:15) at REPLServer.runBound [as eval] (node:domain:443:12) at REPLServer.onLine (node:repl:927:10) at REPLServer.emit (node:events:532:35) at REPLServer.emit (node:domain:488:12) at [_onLine] [as _onLine] (node:internal/readline/interface:416:12) at [_line] [as _line] (node:internal/readline/interface:887:18)

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

#139

Post by CxByte »

chrismorgan wrote: post #115
vanderZwan wrote: post #110

Earlier quoted context omitted.

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…

> you don’t—you never—pick and choose based on “that thing is obsolete and no one uses it anyway

This might make sense for a complete implementation, but in reality...no one would implement a useless API. Also, if truly no one used it, it would simply not exist (e.g. `with` in module mode), a new implementation of some spec will always pick and choose based on utility and use-cases.

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

#140

Post by apgwoz »

astrobe_ wrote: post #135
apgwoz wrote: post #128

Earlier quoted context omitted.

What happens if there’s a regression in coverage, maybe due to a large sweeping change, and you go from 0.40 -> 0.35 ?

There's the commit hash. Basically the "version number" is the commit hash, the human-generated (version) numbers added to it are merely progress indicators, which might be randomly useful. But for a project that has 1 branch, 0 tags and nearly 2000 commits, that's not really important.

yes, the entire exercise isn’t important. It just breaks the monotonicity that version numbers typically have. At that point, just call your version .sha
Post reply on HN