This is also a result of the detachment of TC39 and the developer community. Just how many JS developers are participating TC39? I can recall multiple TC39 proposals that didn't even consult opinions from authors of notable open-source stakeholder libraries, and went straight into stage 3.
And btw, the TypeScript tooling scene is far from being able to get standardized. TypeScript is basically a Microsoft thing, and we don't see a single non-official TypeScript tool can do type-checking. And there's no plan to port the official tools to a faster language like Rust. And the tsc is not designed for doing tranditional compiler optimizations. The TypeScript team made it clear that the goal of tsc is to only produce idiomatic JavaScript.
I think React would get better developer experience and performance if they adopt language coroutine feature to implement direct style algebraic effect. In fact the React Fiber system is already an implementation of algebraic effect.[1] However, it’s “suspending” a routine by raising an exception. Thus unwinding all the call stack, therefore, it needs to re-run that same routine on resume. This is the core reason why they have a performance issue and why they created the compiler to cache values on reruns.
JavaScript has language level coroutine features like async/await or yield/yield* and we have seen libraries using these features to implement direct style algebraic effect. For example Effect[2] and Effection[3]. You don’t need to memoize things if the language runtime can suspend and resume your functions instead of throwing exceptions and rerun them.
I wish the TypeScript team can actually make a good and fast compiler with type inference support. There are so many opportunities for minimization, optimization, conditional builds, instrumentation, and so on if we can utilize the type info from the TypeScript compiler. Unfortunately the TypeScript team never commit to requests like these, and only commit to idiomatic JavaScript transpilation.[1][2]
And because TypeScript is so complex and development is so heavy, third party attempts on making a type checker have never succeeded.[3]
I'm curious how far React Compiler can go without the access to TypeScript type info, and if they would invest in compiler tooling for TypeScript in the future. But considering Meta has Flow as their in-house alternative to TypeScript, they might not have the incentive in investing in the TypeScript ecosystem.
You should do some measurement before calling it an improvement. If you read the ECMAScript standard[1] or this blog post from V8[2] about the inner workings of the `await` keyword, you would know even if you `await` a non-Promise value, it would still create a new Promise and put the suspended routine onto the microtask queue. So the change you made won't make a difference.
Besides, there is a JavaScript language feature that can give you finer control on routine suspension and resumption, decoupled from any of the microtask or macrotask queue. It's called the generator function. There are some good coroutine libraries based on generator functions, e.g. co.js[3] and redux-saga[4]. You can easily make something similar that can resume the suspended routine according to your scheduling policy that prioritize main thread rendering.
Most third party keyboards cannot emulate the Globe key. Apple would only recognize it if the USB PID/VID matches real Apple USB keyboards, which third party keyboards are not allowed to use.
IRs aren't generally suited toward small snippets of examination by human when you're starting with a full binary. I would imagine something like that would only work well when done for very small bits of assembly. Likewise, you might be interested in BNIL which is an entire stack of ILs that Binary Ninja is based on. (You can see it exposed in the cloud.binary.ninja UI or the demo)
Qemu works by translating a binary to an IR then doing stuff with it. Valgrind likewise. There's an optimiser called bolt (associated with facebook) which has the same idea.
Yup, I'm aware of both of those, but none of those tools listed so far are intended for the IR to be for human-consumable unlike disassemblers and decompilers. You think disassembly is verbose compared to a decompiler? Go look at the equivalent Vex (Valgrind's IR) for any non-trivial disassembly. It's suuuper verbose.
As far as I know, BNIL (https://docs.binary.ninja/dev/bnil-overview.html) is the only one that is designed to be readable and it still wouldn't make sense to include it in an IL comparison such as the one done here for decompilation in my opinion.
