Static TypeScript: A Static Compiler for the TypeScript Language

Hey HN, I work at MSFT on MakeCode.com [5] which is the primary user of Static TypeScript. Happy to answer questions. Michal and others who worked on STS more directly will probably be online in a couple hours.

One important clarification: So far STS has been built specifically to target microcontrollers/MCUs. Initially it was targeted at the BBC micro:bit [0] for educational purposes and has since grown to support many more targets ([1],[2],[3],[4],[5]). The other dominant languages in this space are MicroPython and the AVR/Arduino language. The advantages of STS are beginner friendliness (makecode is a CS EDU platform), low-memory, small size and performance (relative to MicroPython). It's worth noting that in general STS is NOT faster than running JS in V8.

How does it compare to MicroPython?

- Error reporting: Because STS is statically typed and compiled, most program errors are caught in the editor before the program is loaded on the device. Furthermore, STS comes with a simulator that runs in the browser and so programs can be tested there before they run on hardware. For educational purposes, we found diagnosing issues on hardware to be really hard for students, so we try to catch and present errors as early as possible.

- Performance: [3] is the best example of this. Usually we notice STS is ~10x faster than uPython while having a smaller flash and memory footprint. This makes running a game loop at 30FPS feasible on a 120x160 display (e.g. this [6] $25 device).

How does it compare to AVR/Arduino/C/C++?

- Modern language: STS, like TypeScript, heavily uses type inference, supports advanced types constructs like algebraic types (i.e. sum/union and product/tuples), supports ducktyping, has easy to use lambdas, has a light-weight syntax, and favors event-based programming.

- Teachability: Because of the heavy use of type inference, most beginner programs have no type annotations and it looks just like Javascript. So we essentially teach JS to users after they want to move on from blocks.

- In general STS is not faster or smaller than AVR code!

Happy to answer other questions!

[0] https://makecode.microbit.org

[1] https://makecode.adafruit.com

[2] https://maker.makecode.com

[3] https://arcade.makecode.com

[4] https://makecode.mindstorms.com

[5] https://makecode.com

[6] https://www.adafruit.com/product/3939

I wouldn't say all the JS mainstays are gone. In fact, most STS programs have little to no type annotations, so it very much looks like javascript still. The dynamic parts like eval() and "new function" are gone, but the others you mentioned could likely be added in the future. Date() for example isn't added because STS mostly targets MCUs which don't typically have persistent time.

STS was designed and built to target MCUs for educational purposes. It's actually incompatible with pretty much every NPM package out there TypeScript or not, because 99% of those can't fit or run on an MCU.

> So? Is there a reason left then to use Typescript instead of C or C++? I cannot think of one.

How about memory safety and type inference?

This isn't wrong and that is one of the largest issues people have with C++: if something is syntactically correct in a language, chances are you'll find it in any relatively big codebase - and with C++ there are a LOT of things that are syntactically correct.

It may feels nice preaching that C++ is only whatever subset you may like (and there are a LOT of C++ programmers, or "programmers who write code that happen to be accepted by C++ compilers" if you prefer, that do that - personally i like pre-C++98 subset that was implemented in Borland C++ Builder 1) but in practice when you have to deal with a real world big C++ codebase (especially something you didn't write yourself and didn't start last month) you'll see all the faces of C++ at the same time, either you like it or not.

Extremely interesting idea. Sounds like many of the things they get rid of are some of the more problematic features of JS anyway. The end result is fairly Swift-y; a loosely OOP static language that has closures and really convenient hash-map syntax.