5 ms·

> What are good use cases for AssemblyScript? > Computation-heavy logic like image manipulation, hot game logic, specialized algorithms, emulators, compilers a

> What are good use cases for AssemblyScript? > Computation-heavy logic like image manipulation, hot game logic, specialized algorithms, emulators, compilers and the likes are great use cases for WebAssembly, and as such for AssemblyScript as well. In some situations it may also be preferable to ship bytecode instead of minified JS, or just the ability to utilize a TypeScript-like language may open up new opportunities, for example for embedded scripting or plugins. That doesn't really answer the question of why you would want to use AssemblyScript instead of eg C++ or Rust. It's not as if you get any of the benefits of Javascript, except for a familiar syntax.

qsort 4y ago
> [...] For example, TypeScript tooling can be used to author and refactor AssemblyScript code and, with some effort, the same code base can be transpiled to JavaScript with tsc and compiled to WebAssembly with asc, or code shared. The AssemblyScript compiler itself is portable.
pjmlp 4y ago
Easier toolchain, right now targeting WebAssembly with most backends it still a kludge, of duct taped tools, while AssemblyScript is a npm install away and the familiar syntax is a big win regarding adoption.
- intelVISA 4y ago
  It's pretty amazing just how bad the tooling still is for Wasm given how much it's been pushed. (I'm a fan of wasm conceptually... I just can't handle all the Emscripten-kludge)
  - flohofwoe 4y ago
    Compared to similar compiler toolchains like the Android NDK or the MSVC command line tools, Emscripten really isn't that bad (for a C/C++ toolchain). Dramatically improving things would most likely mean becoming incompatible with mainstream C/C++ compiler toolchains (after all, the Emscripten compiler and linker needs to be pluggable into existing C/C++ build systems).
    - pjmlp 4y ago
      It isn't as bad as Symbian C++ used to be juggling MS-DOS batch files, Perl, make and Carbide/Metrowerks project files, but it could have less third party depedencies, between Python, node, Java, cmake and make. Ideally targeting WebAssembly from C and C++ compilers should be a -march switch, and Emscriptem would fade out.
      - flohofwoe 4y ago
        There's actually a super interesting project called wajic here: https://github.com/schellingb/wajic https://github.com/schellingb/wajic It's basically clang plus wasm-opt and some magic pixie dust which enables some of the most important features of Emscripten, but without the whole 'technology zoo' :)
        pjmlp 4y ago
        Thanks for the tip.
  - the_duke 4y ago
    The component model [1] with interface types will enable nicer tooling for things like linking and combining different languages, but it's been very slow moving and is still in flux. [1] https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model
    - pjmlp 4y ago
      They keep reinventing what other polyglot bytecode environments already did, but they weren't part of a design by committee workflow.
flohofwoe 4y ago
It's somewhat subjective, but the core of Typescript which AssemblyScript uses for 'inspiration' is a much smaller and 'friendlier' language than C++ or Rust. Unlike C++ or Rust you can learn the whole language in an afternoon or at most a weekend, and if you already know TypeScript anyway you also already know AssemblyScript. Basically, the question "when targeting WASM, why should I use C++ and Rust instead of AssemblyScript" is just as valid. In the end the language choice is most likely enforced by what libraries one needs to use for a specific project anyway (e.g. if you need to build a project on top of a handful C++ libraries, it's probably a good idea to use C++ for the whole project too - and at least there is such a choice now when targeting the web).
- wokwokwok 4y ago
  Hm. > Basically, the question "when targeting WASM, why should I use C++ and Rust instead of AssemblyScript" is just as valid. …but, if you want to write typescript then why not just write typescript? If you want better performance surely tier 1 support for wasm, for example, for typescript, it a categorically better solution for everyone, with no need for an entirely new language? A good comparison is rust-gpu: this is an approach to let you write gpu shaders in rust. The toolchain is different, but you write rust. You compile it. It runs on gpus. Not everyone needs, or wants to do this, but for people who need a) very high performance, b) existing tooling, you can do it, and it saves you writing shaders in c. When rust releases a new version, the same rust compiler compiles new rust code and new rust syntax for gpu. So… the parallels are clear, except assemblyscript seems to have missed the boat by deciding to invent a new language with high level similarity but not quite the same” semantics. ..and when typescript continues to evolve? Will assemblyscript forever be playing catch-up to new typescript syntax? Or fall behind the rentless march of the Microsoft/typescript release cycle? What about when Microsoft decides to make this a first class feature of typescript itself? I think that’s not really that unlikely if it means significant performance gains. I feel this is a missed opportunity. What you wanted was to be able to compile typescript to wasm, not a new language.
  - the_duke 4y ago
    Typescript doesn't have semantics on its own. It's a syntax for JavaScript with a static type checker on top. A lot of JavaScript isn't really suitable for a low level language because of GC, heavy use of very flexible objects, any, only a number type instead of int8/16/... and float32/64, ... Assemblyscript is essentially a very restricted, low level variant of TS. If you really want JavaScript in WASM, you can already get that by using Spidermonkey compiled to WASM as an interpreter. A compiled version of TS could be interesting, but would be a lot of work and would come with a lot of difficult challenges for getting could performance. I will say though that I'd much rather use Rust than AS though, so I do see how the language has limited appeal.
jillesvangurp 4y ago
Assembly script is a lot easier to pick up than C++ and Rust; especially for people coming from a typescript or javascript language background (i.e. web developers). And it's not like you are going to get a huge performance benefit using Rust or C++ over assembly script. It's the compiler that makes things fast and the idioms. And basically the compiler toolchain is very similar for assemblyscript. The only real difference with assembly script is that it's a garbage collected language. Otherwise, it uses llvm and the same set of optimizations you'd be getting with C++ and Rust.
- CryZe 4y ago
  > And it's not like you are going to get a huge performance benefit using Rust or C++ over assembly script. Or do they? Unlike Assembly Script, Rust and C++ use LLVM, which is a lot better at optimizing than binaryen.
  - flohofwoe 4y ago
    What really counts for performance on modern CPUs are memory access patterns, if those are bad, LLVM's optimizer passes won't help much - especially since WASM itself is fairly highlevel too and requires further optimization when translated to machine code anyway. A more interesting question is instead: does AssemblyScript allow the same control over memory layout as C, C++ or Rust?
    - CryZe 4y ago
      I don't think I agree. A debug build of Rust code is often like 40x slower or so than a release build. Those optimizations make a huge difference. Binaryen can only do a fraction of them, so I wouldn't expect AssemblyScript to get close to Rust and C++ (and the benchmarks show that too). > does AssemblyScript allow the same control over memory layout as C, C++ or Rust? There's no UB, so in a way AssemblyScript is almost more low level than those, as you have full control over the memory and instructions.
      - flohofwoe 4y ago
zarzavat 4y ago
AssemblyScript is nice for small units of code that you might want to accelerate in a larger TypeScript project. The mental context switch is much less because the syntax and some of the tooling is the same, you only have to adjust for the semantics. It isn't designed for or suitable for large projects. The other reason to use it is that it's much closer to WASM than Rust or C++. It's the closest you can get to writing WASM without writing WASM.
- maxgraey 4y ago
  > It isn't designed for or suitable for large projects. Why? The compiler itself is written in AssemblyScript and is capable of bootstrapping. The AS code base is quite large. In addition, there are other quite large projects. For example: https://github.com/acutmore/type-off https://github.com/acutmore/type-off. It's port of "sucrase" project (which functionally equivalent to esbuild or swc)

qsort 4y ago

> [...] For example, TypeScript tooling can be used to author and refactor AssemblyScript code and, with some effort, the same code base can be transpiled to JavaScript with tsc and compiled to WebAssembly with asc, or code shared. The AssemblyScript compiler itself is portable.

pjmlp 4y ago

Easier toolchain, right now targeting WebAssembly with most backends it still a kludge, of duct taped tools, while AssemblyScript is a npm install away and the familiar syntax is a big win regarding adoption.

intelVISA 4y ago
It's pretty amazing just how bad the tooling still is for Wasm given how much it's been pushed. (I'm a fan of wasm conceptually... I just can't handle all the Emscripten-kludge)
- flohofwoe 4y ago
  Compared to similar compiler toolchains like the Android NDK or the MSVC command line tools, Emscripten really isn't that bad (for a C/C++ toolchain). Dramatically improving things would most likely mean becoming incompatible with mainstream C/C++ compiler toolchains (after all, the Emscripten compiler and linker needs to be pluggable into existing C/C++ build systems).
  - pjmlp 4y ago
    It isn't as bad as Symbian C++ used to be juggling MS-DOS batch files, Perl, make and Carbide/Metrowerks project files, but it could have less third party depedencies, between Python, node, Java, cmake and make. Ideally targeting WebAssembly from C and C++ compilers should be a -march switch, and Emscriptem would fade out.
    - flohofwoe 4y ago
      There's actually a super interesting project called wajic here: https://github.com/schellingb/wajic https://github.com/schellingb/wajic It's basically clang plus wasm-opt and some magic pixie dust which enables some of the most important features of Emscripten, but without the whole 'technology zoo' :)
      - pjmlp 4y ago
        Thanks for the tip.
- the_duke 4y ago
  The component model [1] with interface types will enable nicer tooling for things like linking and combining different languages, but it's been very slow moving and is still in flux. [1] https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model
  - pjmlp 4y ago
    They keep reinventing what other polyglot bytecode environments already did, but they weren't part of a design by committee workflow.

flohofwoe 4y ago

It's somewhat subjective, but the core of Typescript which AssemblyScript uses for 'inspiration' is a much smaller and 'friendlier' language than C++ or Rust. Unlike C++ or Rust you can learn the whole language in an afternoon or at most a weekend, and if you already know TypeScript anyway you also already know AssemblyScript. Basically, the question "when targeting WASM, why should I use C++ and Rust instead of AssemblyScript" is just as valid. In the end the language choice is most likely enforced by what libraries one needs to use for a specific project anyway (e.g. if you need to build a project on top of a handful C++ libraries, it's probably a good idea to use C++ for the whole project too - and at least there is such a choice now when targeting the web).

wokwokwok 4y ago
Hm. > Basically, the question "when targeting WASM, why should I use C++ and Rust instead of AssemblyScript" is just as valid. …but, if you want to write typescript then why not just write typescript? If you want better performance surely tier 1 support for wasm, for example, for typescript, it a categorically better solution for everyone, with no need for an entirely new language? A good comparison is rust-gpu: this is an approach to let you write gpu shaders in rust. The toolchain is different, but you write rust. You compile it. It runs on gpus. Not everyone needs, or wants to do this, but for people who need a) very high performance, b) existing tooling, you can do it, and it saves you writing shaders in c. When rust releases a new version, the same rust compiler compiles new rust code and new rust syntax for gpu. So… the parallels are clear, except assemblyscript seems to have missed the boat by deciding to invent a new language with high level similarity but not quite the same” semantics. ..and when typescript continues to evolve? Will assemblyscript forever be playing catch-up to new typescript syntax? Or fall behind the rentless march of the Microsoft/typescript release cycle? What about when Microsoft decides to make this a first class feature of typescript itself? I think that’s not really that unlikely if it means significant performance gains. I feel this is a missed opportunity. What you wanted was to be able to compile typescript to wasm, not a new language.
- the_duke 4y ago
  Typescript doesn't have semantics on its own. It's a syntax for JavaScript with a static type checker on top. A lot of JavaScript isn't really suitable for a low level language because of GC, heavy use of very flexible objects, any, only a number type instead of int8/16/... and float32/64, ... Assemblyscript is essentially a very restricted, low level variant of TS. If you really want JavaScript in WASM, you can already get that by using Spidermonkey compiled to WASM as an interpreter. A compiled version of TS could be interesting, but would be a lot of work and would come with a lot of difficult challenges for getting could performance. I will say though that I'd much rather use Rust than AS though, so I do see how the language has limited appeal.

jillesvangurp 4y ago

Assembly script is a lot easier to pick up than C++ and Rust; especially for people coming from a typescript or javascript language background (i.e. web developers). And it's not like you are going to get a huge performance benefit using Rust or C++ over assembly script. It's the compiler that makes things fast and the idioms. And basically the compiler toolchain is very similar for assemblyscript. The only real difference with assembly script is that it's a garbage collected language. Otherwise, it uses llvm and the same set of optimizations you'd be getting with C++ and Rust.

CryZe 4y ago
> And it's not like you are going to get a huge performance benefit using Rust or C++ over assembly script. Or do they? Unlike Assembly Script, Rust and C++ use LLVM, which is a lot better at optimizing than binaryen.
- flohofwoe 4y ago
  What really counts for performance on modern CPUs are memory access patterns, if those are bad, LLVM's optimizer passes won't help much - especially since WASM itself is fairly highlevel too and requires further optimization when translated to machine code anyway. A more interesting question is instead: does AssemblyScript allow the same control over memory layout as C, C++ or Rust?
  - CryZe 4y ago
    I don't think I agree. A debug build of Rust code is often like 40x slower or so than a release build. Those optimizations make a huge difference. Binaryen can only do a fraction of them, so I wouldn't expect AssemblyScript to get close to Rust and C++ (and the benchmarks show that too). > does AssemblyScript allow the same control over memory layout as C, C++ or Rust? There's no UB, so in a way AssemblyScript is almost more low level than those, as you have full control over the memory and instructions.
    - flohofwoe 4y ago

zarzavat 4y ago

AssemblyScript is nice for small units of code that you might want to accelerate in a larger TypeScript project. The mental context switch is much less because the syntax and some of the tooling is the same, you only have to adjust for the semantics. It isn't designed for or suitable for large projects. The other reason to use it is that it's much closer to WASM than Rust or C++. It's the closest you can get to writing WASM without writing WASM.

maxgraey 4y ago
> It isn't designed for or suitable for large projects. Why? The compiler itself is written in AssemblyScript and is capable of bootstrapping. The AS code base is quite large. In addition, there are other quite large projects. For example: https://github.com/acutmore/type-off https://github.com/acutmore/type-off. It's port of "sucrase" project (which functionally equivalent to esbuild or swc)