How to try Static Hermes

[philipheinser]

Are there binaries distributed to try out Static Hermes or should you build it by yourself from the branch?

[shihabmridha]

I cloned the repo, switched to static_h branch, and built the project using this document. It generates hermes and shermes in the build/bin/ directory. But, when I run the following code using the hermes index.js command I get the following error.

> hermes index.js
LLVM ERROR: Generating HBC bytecode disabled in Static Hermes

You can execute static-hermes bin though using the command below.

> shermes -typed -exec ./index.js
6 ms, 3.7330486176528693e+164

Code I tried to execute:

function bench (lc, fc) {
    var n, fact;
    var res = 0;
    while (--lc >= 0) {
        n = fc;
        fact = n;
        while (--n > 1)
            fact *= n;
        res += fact;
    }
    return res;
}

let t1 = Date.now();
var res = bench(4e6, 100);
print(Date.now() - t1, "ms,", res);

Unrelated (without the print function call):
time shermes -typed -exec index.js
0.12s user 0.09s system 22% cpu 0.938 total
time node index.js
0.42s user 0.03s system 85% cpu 0.532 total
time bun index.js
0.30s user 0.03s system 89% cpu 0.363 total

[tmikov]

time shermes -typed -exec index.js

Just want to point out that this is measuring the time to compile and link a native binary on disk.

[tmikov]

There are no binaries, and be warned: it is not ready to be tried out, since what works or doesn't is not documented, or it may even change or regress from commit to commit.

With that said, if you insist on trying it, you need to build it.

[gauravgautamapptile]

Hello, I am also very curious about static hermes. I tried to compile it and run it and was able to do some things. I noted down my steps here: https://medium.com/@gautam1168/compiling-typescript-to-native-code-0238d69ca582

I am not sure if sharing this is not appreciated since I am obviously not familiar with hermes and so might have done many things that could mislead someone. If that is the case you can delete my comment or I will if you tell me to.

[tmikov]

We absolutely welcome posts like this and thank you for sharing it.

I would add just a few clarifications:

1. The instructions in your blog post compile Static Hermes in debug mode, so it will be very slow.
2. The C output is a temporary feature to simplify our development (C code is easier to understand than LLVM IR). You can use -g to annotate it with #line directives, which actually enable you to partially debug the original JS in a native debugger.
3. TypeScript support is experimental and incomplete (but we are always improving it).

[thejustinwalsh]

I was able to get the benchmarks building using the following...

cmake -S hermes/benchmarks -B build_benchmarks -DHERMES_BUILD=/absolute/path/to/hermes/build -DHERMES_SRC=/absolute/path/to/hermes
cmake --build ./build_benchmarks 

The raytracer benchmark is a wonderful example of a full application using shermes, as it has bindings to ImGui, and uses sokol to get a window and rendering context setup.

I was going to take a stab at some Raylib bindings after I dig into ffigen a bit deeper.

[tmikov]

Really cool! BTW, we are still working on the performance of that benchmark, it will get faster.

[gauravgautamapptile]

Hello, I had not even expected that my post will be read by so many people including yourself. This email made my morning. I will update my post tonight to note how to compile in release mode. And I was going to try debugging using visual studio. I will attempt to get the typescript code to show up in my native debugger. Thankyou for that pointer. Yours sincerely, Gaurav Gautam

…

On Thu, 5 Oct 2023 at 23:15, Tzvetan Mikov ***@***.***> wrote: We absolutely welcome posts like this and thank you for sharing it. I would add just a few clarifications: 1. The instructions in your blog post compile Static Hermes in debug mode, so it will be very slow. 2. The C output is a temporary feature to simplify our development (C code is easier to understand than LLVM IR). You can use -g to annotate it with #line directives, which actually enable you to partially debug the original JS in a native debugger. 3. TypeScript support is experimental and incomplete (but we are always improving it). — Reply to this email directly, view it on GitHub <#1137 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBZ6O4CSECQVWXDZS4AHJJTX53W27AVCNFSM6AAAAAA5N3XTHCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TEMBRGUZTS> . You are receiving this because you commented.Message ID: ***@***.***>

[thejustinwalsh]

I spent an evening creating a turn-key example of using shermes with typescript here:
https://github.com/thejustinwalsh/sh-raylib

I tried my best to automate a bunch of concepts found in the other examples...

• CMake generates the raylib ffi files and concats the results with the includes as a part of the build process
• Using FetchContent for both hermes and raylib to make it easier to setup the workspace
• VSCode creature comforts

hello-world: https://github.com/thejustinwalsh/sh-raylib/blob/main/src/hello-world/hello-world.ts

bunny-mark: https://github.com/thejustinwalsh/sh-raylib/blob/main/src/bunny-mark/bunny-mark.ts

Not for the faint of heart, but lots of fun to hack on!
If you are familiar with C/C++ and CMake, you will feel right at home. I had to refactor my bunny-mark.ts code a few times to work around things that were not implemented or produced unexpected results.

I still don't understand a good strategy for managing the lifetimes of the heap allocations vs the JS objects that rely on them.

I hope this helps anyone else who is interested in hacking on it.
If there are ways that you would prefer I contribute back, LMK, at this point, I am not sure if making extra noise with bugs and failing tests is warranted.

[thejustinwalsh]

@tmikov 🥳

Runtime	FPS	CPU	GPU	Memory
C	90	68%	84%	48 MB
Static Hermes	90	70%	84%	53 MB

Your changes have made this demo run at native speed. This is next level, amazing! 🚀

For the audience:

• I assumed I could only use a class with babel-transform plugins like the ones used in @react-native/babel-preset, as the docs have it listed as planned on Hermes main. This is closer to the original implementation as well, so it is a better 1:1 comparison.
• I didn't know about _sh_ptr_write_c_uint and my first attempt at this code failed when I was attempting to do pointer math with the wrong helpers. This is the way.
• This is more concise and carries the intention better, love it.

TLDR; Static Hermes is fast!

[quadband]

What does the “inline” literal expression do in the makeColor function? What is interpreting it?

[tmikov]

It marks the function as inline, so it will be inlined at every call site, regardless of its size or other heuristics.

[quadband]

Thank you. Is this Hermes Static only? I spent the last half hour trying to find a reference to it and didn’t have any luck. I appreciate you answering.

[tmikov]

Yes, it is Static Hermes only, but does no harm in other engines. It will be documented eventually, when we are close to release.

[jerrygreen]

I really want some npm install -g shermes or something.

[HarunaMahjong]

@tmikov Is there a plan for Static Hermes to support JIT compilation for bytecode that has not been AOT compiled into machine code?

[tmikov]

@HarunaMahjong there are no plans to ever implement an advanced speculating JIT similar to JSC or v8.

[HarunaMahjong]

@tmikov And one more thing to ask. Will Static Hermes support TypeScript? If so, will it compile TypeScript into JavaScript with all type information removed, or will it use some of the type information included in TypeScript for AOT compilation to native binary in Static Hermes?

This is already supported, with initial types contributed by Amazon, I believe, and a few more community contributions have happened here as well. It uses the type information to inform the AOT compilation.

@thejustinwalsh, I would like to find information about the initial types contributed by Amazon and TypeScript. Could you please provide some links?

[gauravgautamapptile]

@HarunaMahjong im not sure if this is what you are looking for but this commit has what looks like a typescript parser: https://github.com/facebook/hermes/blob/6a842d01016d86dca63d8247f9853c3c7b33ba1e/lib/Parser/JSParserImpl-ts.cpp

There are other PR's merged later on that touch this file that are from someone from amazon: #1115
#1173

From what I can understand of this (which is not much since its c++ code), its creating some AST that contains the type information. I don't know at which point this goes into the compiler though, it is much beyond my ability. However Ill try a shot in the dark:

1. This JSParserImpl-ts.cpp is an implementation of JSParser which is being linked with shermes.cpp in one of the make files
2. If you follow the #includes in shermes.cpp you will eventually get to JSParserImpl-ts.cpp. They are connected in some way.
3. In shermes.cpp there is a line which goes parsedAST = convertTSToFlow(*context, parsedAST); where the input is the AST from the typescript parser.
4. This function is invoked from compileFromCommandLineOptions, which I think is what actually compiles the ts files.
5. compileFromCommandLineOptions takes the ast and converts it to IR in the line that goes generateIRFromESTree(&M, semCtx, flowContext, ast);
6. This stores the IR in the variable M which is then passed to functions that seem like are invoking llvm in later steps like runCustomOptimizationPasses(M, cli::CustomOptimize) and runFullOptimizationPasses(M).
7. Then the PM (the passmanager) is adding what looks like optimization passes like PM.addLowerGeneratorFunction(), PM.addFunctionAnalysis();.
8. I hit a deadend if I try to get my IDE to show the code for these passes though.

So, I guess hermes will take the typescript file and convert it to an ast which was provided by the PR's above. Then convert it to a flow-ast, and then to an IR which is then optimized using optimization passes that may or may not be defined inside this codebase itself (i cannot tell). How exactly the types in the flow ast help the compiler is not known to me. But I guess it might be either helping the function that is generating the IR or it is affecting the kind of IR that is generated by that function.

To your point, I don't think this is converting typescript to javascript at any point. But the typescript ast is being converted to flow ast though. After that it goes to the llvm IR I think and never comes back to text form.

[HarunaMahjong]

@gauravgautamapptile Wow, that's a really long response. Thanks to you, I can get a rough idea of the content. Really, thank you so much.

[gauravgautamapptile]

I was trying to run the code in the 300x benchmark and I was able to follow the article. I wasn't able to setup lldb properly to step through the assembly though. Stepping would be ideal in trying to understand the compiled output instead of just looking at the assembly dumps. I am able to step through using vscode and I can see some of the things mentioned in the article there.

but is it not possible to make it step into the javascript function? I can step through the assembly but the debugger isn't able to show me the location in the javascript code. The breakpoint in the bench function doesn't fire. Only the other one does. And if I try to debug the executable using lldb console I am still not able to see the source by running list.

I created the executable using this command

~/workingdir_hermes/build_release/bin/shermes -g -o bench bench.js

and there is a bench.dSYM file in the directory alongside the bench executable so I think the debugging symbols are there. But somehow my lldb can't figure it out maybe? Im new to trying to debug assembly so is there something obvious Im missing here?

[SichangHe]

2700 commits ahead of main. Did you guys write any documentation 😅?

[vExcess]

@gauravgautamapptile
I can't seem to get FFI working. Whenever I run shermes -typed -exec -lmyfunc.o ./yourfile.ts I get /usr/bin/ld: cannot find -lmyfunc.o: No such file or directory. I have tried everything I can think of
shermes -typed -exec -llib/myfunc.o ./yourfile.ts
shermes -typed -exec -Llib -llib/myfunc.o ./yourfile.ts
shermes -typed -exec -lmyfunc.o ./yourfile.ts // copied the myfunc.o to the base directory
shermes -typed -exec -lmyfunc.o -Wc,-Llib,-lmyfunc.o ./yourfile.ts

Nothing works. Everything logs /usr/bin/ld: cannot find -lmyfunc.o: No such file or directory.

Lastly I tried shermes -typed -exec -lmyfunc.o -Wc,-Wl,--verbose ./yourfile.ts This should make shermes cause cc to cause the linker to be verbose, but I got another error cc: error: unrecognized command-line option ‘-Wl’; did you mean ‘-W’? even though cc --help shows that it is in fact a valid command-line option -Wl,<options> Pass comma-separated <options> on to the linker.. So I replaced it with -W and it dumped a bunch of data, but none of it indicates why the linker is failing.

Has Static Hermes changed the way that I have to link my .o file? Also I am 100% certain that the myfunc.o does in fact exist.

It'd be nice if Meta wrote documentation for the project.

[tmikov]

@vExcess please note that TextDecoder and TextEncoder are not part of the EcmaScript spec and as such no JS engine is expected to support them. Functionality like that is provided by a JS runtime like Node, Deno, Bun, a browser, etc.

It was never our projects goal to be a JS runtime - that is an undertaking of quite a different nature. Note that none of the runtimes I mentioned above are developed by the v8 or JSC teams respectively. They are separate projects, often by unrelated organizations, using the JS engine.

With that said, we are open to packaging some non-ECMAScript functionality with Hermes, for convenience. See #1072. We are hoping that the community may be able to contribute some as well.

[vExcess]

@gauravgautamapptile
I finished my article. It's a long read, but I hope it can be helpful to anyone else trying to use static hermes. Hopefully other people can get use out of the TextDecoder and TextEncoder I've ported to be shermes compatible.
https://vexcess.github.io/blog/creating-a-native-app-in-typescript

Unfortunately I was not able to get my project working. I'm hoping the static hermes devs might take a look at it and figure out why it's seg faulting at 0x00007ffff7e9388a in _sh_fastarray_load () from /home/vexcess/shermes-linux-x86_64/build_release/lib/libhermesvm.so

But I'll be taking a break from the project for a while and will be focusing on a different project where me and a few other people are attempting to create a new web browser purely in Zig.

[tmikov]

@vExcess I would be happy to help you figure out why it is crashing. Do you have a minimal repro?

[vExcess]

@tmikov
I stripped down my script to be minimal
https://github.com/vExcess/lnstat/blob/main/src-shermes/minimal.ts

It seems the seg fault is happening at args[i] because i is beyond the length of the array. i should never be out of bounds though because there is a i < args.length. But the reason it's not being stopped by this is because args.length returns 1.93239734168964e-310. But this value changes every run indicating that it's a garbage value. args is declared as args = Array_slice(process.argv, 2, process.argv.length). This makes me think something is going wrong in the Array_slice function. The function is pretty simple and works outside of shermes. Its contents are

let subArr = [];
for (let i = start; i < stop; i++) {
    subArr.push(self[i]);
}
return subArr;

My guesses of what could be going wrong are

1. shermes has a bug in the part of the code that looks up the length of an array
   or
2. shermes has a bug in its implementation of Array.prototype.push that corrupts that array
   or
3. shermes GC is prematurely freeing the array so that accessing it is returning garbage data

Edit: I should probably mention to run ./build-minimal.sh from the src-shermes directory to build the executable and then you can run ./minimal

[avp]

Thanks for the repro, this is a case of incomplete type-inference behavior as it relates to SH's current implementation of "fast arrays", combined with incomplete runtime typechecking behavior. The type inference and runtime type checking are still works in progress.

Doing let subArr = []; isn't allocating a SH fast typed array (instead, it's making an ordinary untyped JS array), but the typechecker thinks one is being returned from your slice function. Eventually, either [] should be inferred to be string[] instead of an untyped JS array, or the runtime typecheck should throw a JS error with a good message.

As a workaround, I think you can do

let subArr: string[] = [];

for now.

[ishaan1995]

I was trying to run the static hermes from the static_h branch. Compiled the binary and starting using it and it worked exceptionally well.
I wanted to experiment more and play around setTimeout & promises but it failed with following error

code:

setTimeout(() => {
  print("hello world!")
}, 250);

Command: ./shermes -typed -exec main.ts

Error:

main.ts:12:1: warning: the variable "setTimeout" was not declared in anonymous function
setTimeout(() => {
^~~~~~~~~~
Uncaught ReferenceError: Property 'setTimeout' doesn't exist
    at global (native)

Is this expected? Sorry I am new to this and could not find any docs around same in the repo.
Fyi, tried with both debug & release build process, got same error each time.

[tmikov]

setTimeout() is not provided by Hermes/Static Hermes - the event loop and related functionality needs to be provided by the integrator. One simple example can be seen here: https://github.com/tmikov/hermes-jsi-demos/tree/master/evloop

[vExcess]

Not to discourage shermes. But after being unsuccessful in trying to compile my TypeScript using shermes (see my above post), I rewrote my project in Dart instead. Dart is garbage collected and supports dynamic typing and as a result it was fairly straightforward to rewrite my code into Dart. Unlike shermes, Dart also has a standard library for things like setTimeout. The important thing though is that Dart compiles directly to native binary which means it already does what shermes is trying to accomplish. Although compiling JS directly to native using shermes would be more efficient, I think it would be far easier to take advantage of all the work Google has put into Dart and make a JS to Dart transpiler instead. There doesn't seem to be any JS to Dart transpiler in existence, but there is a TS to Dart transpiler https://github.com/dart-archive/ts2dart/. Granted it hasn't been updated in 8 years and both TS and Dart have changed significantly since then so I doubt it's very operational anymore. But if TS to Dart was possible 8 years ago, then I'm sure that today it would be possible to create a new JS to Dart transpiler that is at least more operational than shermes is today. I would love to get started on a JS to Dart transpiler right now, but I'm focusing on creating a FOSS version of MS Paint 3D because Microsoft is killing it on November 4th. If after Nov 4th nobody else has created a JS to Dart transpiler, then I'll probably get started on making one.

[tmikov]

But if TS to Dart was possible 8 years ago, then I'm sure that today it would be possible to create a new JS to Dart transpiler that is at least more operational than shermes is today.

@vExcess i think you are severely underestimating the challenges associated with compiling the actual semantics of TypeScript, which is fundamentally based on structural typing, as a statically typed language. The challenges of supporting type-safe generics, compatibility of lambdas, etc. You are possibly also underestimating the value, as well as the difficulty, of compatibility with existing JavaScript and mixing it with the typed language. None of these can be addressed by a TS to Dart converter.

With Static Hermes we are trying to accomplish a very ambitious task (at least that is how it looks to us) which takes time and effort. As we have stated many times, the typed frontend is not ready for public consumption yet.

Dart is a great language developed from scratch with very different constraints. If it meets your requirements, you should definitely use it. Additionally, if you believe you can achieve and exceed the goals that we have set for Static Hermes by writing a TS to Dart transpiler, you should try that and publish it under a permissive license. If you find innovative ways to solve the complex problems we are facing, we will gladly adopt your solutions.

[jroweboy]

I couldn't decide if this is an appropriate place to request features for static hermes, so apologies if this isn't the right place. I ran into the error error: Legacy JS classes not supported (yet)

I'm not sure if you need any sample projects that use native JS classes, but while Zod itself is written in typescript, when its compiled to JS and uploaded to NPM, the library does use them.

[tmikov]

We are very close to landing support for legacy JS classes. They are much slower than SH's "typed classes", but they are part of the language.

[tkpeach]

How can I try static hermes with reactive-native on my mobile device?

[gauravgautamapptile]

Is it possible to get an addition of Uint8Array's values transformed to simple addition instead of _sh_ljs_add_rjs ?

I was wondering if static_h would compile code involving typed array's into something that would be close to how it would work if I wrote a similar thing in C. So, I wrote the following javascript:

(function () {
  function sum(args: number[]) {
    let result = Uint8Array(1);
    for (let index = 0; index < args.length; ++index) {
      result[0] += args[index];
    }
    return result;
  }

  const data = new Uint8Array(5);
  for (let i = 0; i < 5; ++i) {
    data[i] = (Math.random() > 0.5) ? 1 : 0;
  }
  const result = sum(data);
  print(result[0]);
})();

and compiled using

../build_release/bin/shermes -typed -emit-c -o main_opt.c main.js
../build_release/bin/shermes -typed -g -emit-c main.js

I'm assuming that I can use the #line <line_number> main.js markers in the generated main.c file to follow how the javascript is compiled to C, and that this would apply to the final executable that would run wherever static_h is running (my phone or computer).

I am seeing that the line that adds the numbers in the loop of the sum function (line 5)

4    for (let index = 0; index < args.length; ++index) {
5      result[0] += args[index];
6    }

is transformed to

L5:
#line 4 "main.js"
  ;
#line 4 "main.js"
  // PhiInst
#line 5 "main.js"
  locals.head.src_location_idx = 8;
#line 5 "main.js"
  locals.t3 = _sh_ljs_get_by_index_rjs(shr,&locals.t0, 0);
#line 5 "main.js"
  locals.head.src_location_idx = 9;
#line 5 "main.js"
  np1 = _sh_fastarray_load(shr, &locals.t2, _sh_ljs_get_double(np2));
#line 5 "main.js"
  locals.head.src_location_idx = 10;
#line 5 "main.js"
  locals.t3 = _sh_ljs_add_rjs(shr, &locals.t3, &np1);
#line 5 "main.js"
  _sh_ljs_put_by_val_strict_rjs(shr,&locals.t0, &np4, &locals.t3);
#line 5 "main.js"
  np2 = _sh_ljs_double(_sh_ljs_get_double(np2) + _sh_ljs_get_double(np3));
#line 4 "main.js"
  np1 = _sh_fastarray_length(shr, &locals.t2);
#line 4 "main.js"
  np1 = _sh_ljs_bool(_sh_ljs_get_double(np2) < _sh_ljs_get_double(np1));
#line 4 "main.js"
  if(_sh_ljs_get_bool(np1)) goto L5;
#line 4 "main.js"
  goto L6;

So, I can see the loop condition check

#line 4 "main.js"
  np1 = _sh_ljs_bool(_sh_ljs_get_double(np2) < _sh_ljs_get_double(np1));
#line 4 "main.js"
  if(_sh_ljs_get_bool(np1)) goto L5;

and the line thats doing the addition

#line 5 "main.js"
  locals.t3 = _sh_ljs_add_rjs(shr, &locals.t3, &np1);

But this is using _sh_ljs_add_rjs which adds SHLegacyValue which represents javascript types. I thought this might be happening because the sum function is taking number[] and its throwing the whole thing off. So then I tried with this javascript:

(function () {
  function sum(args) {
    
  }

  const data = new Uint8Array(5);
  for (let i = 0; i < 5; ++i) {
    data[i] = (Math.random() > 0.5) ? 1 : 0;
  }

  let result = Uint8Array(1);
  for (let index = 0; index < data.length; ++index) {
    result[0] += data[index]; // <-- line 13
  }
  print(result[0]);
})();

But still the C output has _sh_ljs_add_rjs, although the _sh_fastarray* things have disappeared:

|#line 13 "main.js"
  locals.head.src_location_idx = 10;
#line 13 "main.js"
  locals.t4 = _sh_ljs_get_by_index_rjs(shr,&locals.t0, 0);
#line 13 "main.js"
  locals.head.src_location_idx = 11;
#line 13 "main.js"
  locals.t3 = _sh_ljs_get_by_val_rjs(shr,&locals.t2, &np2);
#line 13 "main.js"
  locals.head.src_location_idx = 12;
#line 13 "main.js"
  locals.t3 = _sh_ljs_add_rjs(shr, &locals.t4, &locals.t3);
#line 13 "main.js"
  _sh_ljs_put_by_val_strict_rjs(shr,&locals.t0, &np4, &locals.t3);
#line 13 "main.js"
  np2 = _sh_ljs_double(_sh_ljs_get_double(np2) + _sh_ljs_get_double(np3));

I looked at the code of _sh_ljs_add_rjs and there is a LLVM_LIKELY check that exits with a simple addition there, but not before using a pointer to SHLegacyValue to get the numbers. So, javascript engines still treat values inside typed arrays as some complext pointers that need to be cast to numbers and its not like just offsetting in a block of memory like would happen in something like uint8[] type in c?

That name SHLegacyValue is making me think there is some kind of non legacy type that I can somehow generate that would bypass these checks. I guess its a good thing that even typed arrays are thoroughly checked in javascript engines. But, I want to ask if there is something "edgier" that will let me shoot my foot like C that I'm missing. Is there something like a SHUInt8Value that I can get my javascript to generate that would result in an output that is just directly adding those numbers and crashing/overflowing/underflowing if something is incorrect?

Finally, even though I can get the fast_array stuff to disappear, the way the values are accessed from the typed array seems to still be through _sh_ljs_get_by_val_rjs which is doing a lookup inside a javascript object (from what I can understand). I used to think that typed array's value lookups have special handling inside javascript engines which makes them faster than lookups inside regular objects (like those made using object literals). So, does that mean that a typed array is not that different from a normal (i.e. one created using a literal []) from the point of view of my javascript function that is just adding numbers? If the access is always through a function like _sh_ljs_get_val_rjs it wouldn't matter if I used a typed array or a regular array.

I realize that some of this may be too generic (as in asking about javascript engines in general rather than static_h itself), and if that is polluting the thread I will delete my question if mods tell me to.

[tmikov]

@gauravgautamapptile it is always nice to see such in depth questions and people digging into the internals. Of course we are not asking you to delete your question! 😜 Please, keep them coming!

The short answer is that SH type system still doesn't know about typed arrays and about integers, so the compiler isn't able to emit efficient code for your case.

This is a major part of our plans, we simply haven't gotten around to it yet. The main design problem is how to encode types like Uint8Array, Int32Array, etc, without hardcoding them in the compiler. The implementations need to be written in typed JS, much like their equivalents in C++ or Rust, so the compiler will just handle them like any user type. This means that Uint8Array is no longer something internal , it becomes just a regular type, no different other custom types that can be provided by the user.

This is not entirely trivial to do, particularly because we must remain 100% syntactically compatible with Flow and TypeScript.

There is an additional non-trivial challenge related to array handling and to integer typed arrays - JavaScript, including its typed dialects, has no explicit support for integers. Sure, there are implicit integers, like when you do x | 0, but that is not sufficient for a static AOT compiler.

If we look at a simple loop like this:

for (let index = 0; index < args.length; ++index)

we can infer that index is a number, but we can't statically infer that it is an integer, unless we also know that args.length is an integer. The existing type systems (Flow and TS) can't explicitly do this, so we need to extend them and add rules for integer operations that are intuitive to JS developers, who are used to floating point arithmetic.

Additionally, we need to declare the element type of Uint8Array, Int32Array, etc, without "magical" compiler internals.

This is all in progress. I hope this throws some light on the challenges.

Looking at your example, I want to explain a couple of things:

function sum(args: number[]) {...}
...
const data = new Uint8Array(5);
...
sum(data);

Since, as I mentioned, the compiler doesn't know about Uint8Array, the variable data is assumed to have type any. When you later call sum(data), the compiler silently converts any to number[] by issuing a runtime checked cast. This checked cast should fail at runtime and throw an exception, because Uint8Array is not compatible with number[]. However not all checked casts are fully emitted yet, so what you will get in practice here is likely a crash.

Then inside of function sum() you have this code:

let result = Uint8Array(1);
...
result[0] += args[index];

Here result is also inferred to have type any. result[0] also has type any, so the addition is between any and number is treated by the compiler as untyped addition.

If you changed function sum() to look something like this:

function sum(args: number[]): number[] {
    let result : number[] = [0];
    for (let index = 0; index < args.length; ++index) {
      result[0] += args[index];
    }
    return result;
}

you will see the typed numeric addition. Note that it is still incompatible with Uint8Array and it still suffers from lack of integer support.

I think one of the important takeaways here is that we need to issue warnings when converting from any.

[gauravgautamapptile]

I see. I was trying to not write the number[] types because I was hoping SH will be able to infer the type of Uint8Array and then subsequently reason that the addition is being done on Ints. So right now SH doesn't support specifying ints in that way, but its good to know that Ints are work in progress. I didn't figure out that the inferred types were any though. Yes, it would be good to have indications of where the inferred type is becoming any. That way we could try things and see what types are getting inferred.

I did see in your blogpost on the microbenchmark that you were able to see what types were getting inferred by using -dump-lra and I should have checked that output. But its only occurring to me now after you explained about the any type. Ill use it next time.