assemblyscript VS TinyGo

Incidentally, it’s also what AssemblyScript uses: https://github.com/AssemblyScript/assemblyscript/blob/main/s...

Use it as a Front-End for other low-level languages.

> MHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript?

Check out AssemblyScript which is exactly that:

https://www.assemblyscript.org/

If you're curious, check out AssemblyScript, that might describe better what needs to be cut from TypeScript to make it possible to be compiled to WASM.

This is kinda the idea behind AssemblyScript, but IIRC it's more of a low-level typescript-ish syntax for WebAssembly.

https://www.assemblyscript.org/ maybe, but I'm not sure exactly what you need.

Exactly, WASM was designed to be very very lightweight... you can put a lot of logic into a very small amount of WASM, but you need a good compiler to do that, or write WASM by hand to really feel the benefit. If you just compile Go to WASM, with its GC, runtime and stdlib included in the binary, yeah it's going to be pretty heavy... Rust doesn't have a runtime but as you said, for some reason, produces relatively large binaries (not the case only in WASM by the way). Probably, the best ways to create small WASM binaries is to compile from C or from a WASM-native language like AssemblySCript (https://www.assemblyscript.org).

Well we have all the new ECMA standards that will be introduced in 5 years now. It's looking more like Java actually. its accessor and typing patterns match it the most. TypeScript has had quite the profound influence over future ECMA design. There is a not so well known project called AssemblyScript which I think has a promising future. Since future ecma standards closely resembles it and TypeScripts popularity has exploded I have a feeling it may become a real standard as well.

If you can guarantee that Typescript type hints will always be followed, you can turn it into more optimised code. Unfortunately, this means you've got to break Javascript semantics, so this means creating a new language, but people have done it. For example, AssemblyScript is a language that is designed as a strict subset of Typescript that compiles directly down to WebAssembly instead of Javascript, producing much more efficient code (most of the time). The tradeoff is that it has some slightly different semantics to Javascript, which means your existing codebase — and most of the libraries you use — will probably require some adaption before running correctly in AssemblyScript.

Reading through the documentation, you will understand why this plugin is called "tiny," i.e., the SDK uses the TinyGo compiler instead of the official Go compiler. You can read more about why this is the case on the SDK\'s overview page, but the TLDR version is that the Go compiler can only produce Wasm binaries that run in the browser.

Not only you can fit Go into a kernel, there is at least two products that do so.

TamaGo, used to write the firmware used in USB armory.

https://www.withsecure.com/en/solutions/innovative-security-...

TinyGo, which even has official Arduino and ARM support, and is sponsored by Google

https://tinygo.org/

Ah but that isn't proper Go! Well neither is the C code that is allowed to be used in typical kernel code, almost nothing from ISO C standard library is available, and usually plenty of compiler specific language extensions are used instead.

Reminds me of https://tinygo.org/ - a project that brings Golang to embedded devices, browser (wasm) contexts. Do you converge or diverge from that project?

You should also consider TinyGo. It can compile Go for the Pico, and is starting to get good device support.

Thankfully some folks completly ignored whatever the rest of the world thinks system programming is all about and created:

- TinyGo (https://tinygo.org/), which is acknowledged by people in the industry[0][1]

- TamaGo unikernel on USB Armory secure key (https://www.withsecure.com/de/solutions/innovative-security-...)

And then there is the question if writing compilers, assemblers, linkers is systems programming or not.

[0]-https://www.cnx-software.com/2019/08/28/tinygo-go-compiler-f...

[1]-https://twitter.com/ArmSoftwareDev/status/131680481331796787...

Have you seen TinyGo? In the case of embedded system I would probably still chose C over Rust if the system didn't support dynamic memory allocation, and most embedded systems do not.

>I really hate how for microcontrollers the only two choices are either C++ or Micropython

There's TinyGo as well. https://tinygo.org/

Gist link fixed, thanks. Compared to TinyGo, Go with GOOS=wasip1 will probably generate larger artifacts (at least, for now). This is because it bundles the entire Go runtime. The benefit is that it fully supports goroutine scheduling and non-blocking I/O. TinyGo (I believe) still uses a custom asyncify pass and does not support non-blocking I/O nor basic WASI networking (e.g. https://github.com/tinygo-org/tinygo/pull/2748 never landed, but GOOS=wasip1 supports it).