You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Typescript is no longer a niche language. Large projects and small solutions are written directly in Typescript.
Node, Deno and Bun support TS as something to be converted (lost) on the fly, not as something that can enable important optimizations at runtime. Nova is just another one doing the same.
Just as an engine can be more performant manipulating numbers in a Float64Array than in a generic Array, some runtime benefit can be gained by arr: number = []
When a function is called with incompatible arguments, the engine will not allow the fate to decide application result... In this case the execution will stop and an exception should be thrown. With this approach other optimizations can be achieved, for example: (a:number, b:number)=> a + b, where the + operator will always be an arithmetic operator (no string concatenation will be possible) and no elaborate conversion should be expected.
I've already seen that @load1n9 is moving in this direction, especially working on enums support.
I think Nova should to be a TS first engine to achieve this goal, and JS code will need to receive generic typing (any everywhere) to run. I believe this is positive, so that any project will benefit when at least one module provides typing.
The text was updated successfully, but these errors were encountered:
Porffor actually does this, so we wouldn't be the first :)
But: This is somewhat the plan for the typescript flag, or at least for some typescript-strict flag perhaps? The problem with this as it stands is that the VM isn't built to take advantage of these sorts of optimisations. We have only one instruction for doing + and it handles both string concatenation and arithmetic (number and bigint) sum together.
One of the reasons why the instruction set is so limited is because the instructions are 8 bit numbers: This is much too limited a number range to really have specialised instructions. (The main reason is lack of time and effort, though.) If we eventually move to 16 bit integer instructions though, then we can much more readily add optimised instruction variants. And if optimised variants become the norm then the VM design itself may deserve a change to better reflect that with eg. separate stacks for Value types, references, and stack values.
Typescript is no longer a niche language. Large projects and small solutions are written directly in Typescript.
Node, Deno and Bun support TS as something to be converted (lost) on the fly, not as something that can enable important optimizations at runtime. Nova is just another one doing the same.
Just as an engine can be more performant manipulating numbers in a Float64Array than in a generic Array, some runtime benefit can be gained by
arr: number = []
When a function is called with incompatible arguments, the engine will not allow the fate to decide application result... In this case the execution will stop and an exception should be thrown. With this approach other optimizations can be achieved, for example:
(a:number, b:number)=> a + b
, where the+
operator will always be an arithmetic operator (no string concatenation will be possible) and no elaborate conversion should be expected.I've already seen that @load1n9 is moving in this direction, especially working on enums support.
I think Nova should to be a TS first engine to achieve this goal, and JS code will need to receive generic typing (
any
everywhere) to run. I believe this is positive, so that any project will benefit when at least one module provides typing.The text was updated successfully, but these errors were encountered: