7 ms·

I wrote/maintain Walt. This question comes up a bunch. The two projects are really similar no doubt. I can't speak for AssemblyScript, but my own motivation wa

I wrote/maintain Walt. This question comes up a bunch. The two projects are really similar no doubt. I can't speak for AssemblyScript, but my own motivation was simple. I wanted to learn WebAssembly and I wanted an accessible platform to do so with. At the time this wasn't really possible, tools like emscripten took forever to set up and were clunky to use. Plus I knew C already, I wanted to learn WebAssembly instead. So where Walt is an attempt to write WebAssembly with a familiar syntax, AssemblyScript is an attempt to compile TypeScript to WebAssembly. To do so AssemblyScript comes with many more niceties/features out of the box IIRC, like optional(?) GC for example. Walt makes no such attempts and takes a more DIY approach. Walt also has language extensions, via customizable syntax and compiler pipeline, where AssemblyScript is a TypeScript compiler more or less. My hope is that this allows for a babel-like situation for WebAssembly in the future via the tooling setup for Walt. I don't think this is a goal of AssemblyScript.

burfog 8y ago
Your project is weird to begin with, and then "knew C already" makes it even weirder. The whole point of WebAssembly was to find some way to get away from JavaScript, and to support languages like C. Here you are, going right back to the JavaScript that we've been trying to escape for the past 23 years. Also, on your page you say that "A competent Front-end engineer should be able to edit WebAssembly as easily as any other systems programmer." The "any other" seems to imply that a "Front-end engineer" is a "systems programmer". This is typically not the case.
- abuldauskas 8y ago
  Escaping JavaScript is not a perspective shared by all (most?), though. It's has been a weird and interesting project, but that's not really a bad thing is it.
  - Touche 8y ago
    You'll have to excuse HN Guy that assumes that every project on GitHub is done to try and take over the world and not because, you know, learning is fun. So keep on doing weird things with your weird and awesome language.
  - inferiorhuman 8y ago
    I may be in the minority then: one of the big advantages, for me, of WASM is that I can use not-Javascript in the browser. Some of the issues I have with JS are an artifact of being one of the first things to run in the browser (e.g. atrocious standard library) and some are just baked in poor designs (e.g. implicit type casting, == vs ===). Oh gosh, let's not forget what happens when you try to use map and parseInt together.
    - mr_toad 8y ago
      [‘1’,’2’,’3’,’4’,’5’,’6’,’7’,’8’,’9’,’10’].map(d => parseInt(d)); Returns [1,2,3,4,5,6,7,8,9,10]
      - inferiorhuman 8y ago
        I'd expect your example to return a syntax error as those aren't single or double quotes. Try: ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"].map(parseInt);
        duckerude 8y ago
        Backticks are used for template literals. Try evaluating `2 + 2 = ${2 + 2}`.
        inferiorhuman 8y ago
        Those weren't backticks (`) either. They were "smart" quotes (’ -- you may need a different font to view the differences more readily ’ vs ').
        rounce 8y ago
        But you understood what they meant right?
      - JimDabell 8y ago
        Sure, but you're putting a workaround in – there really shouldn't be any need for that no-op arrow function. But you do actually need it in order to drop all but the first arguments. This is simple, straightforward, and wrong: ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"].map(parseInt) This doesn't work because map() stuffs a counter into the second argument of parseInt(), which is expecting a radix for its second argument. So the iterations of the map go like this: parseInt("1", 0) parseInt("2", 1) parseInt("3", 2) …and so on, which obviously gives garbage results. JavaScript is littered with these kinds of weird edge cases. Even your example with the workaround isn't 100% reliable, it's browser-dependent – when you have leading zeros in your strings, some browsers will interpret them as octal, and some won't.
- kristofferR 8y ago
  What a weird argument. C is not "better" than Javascript, it is vastly worse for the vast majority of current Javascript uses - where raw performance is a less important consideration than development time. Javascript is far from perfect, but it has improved by leaps and bounds the last few years. WebAssembly is great, but a variant of Javascript or other high-level languages will continue to dominate web development, not C. People aren't going to "escape" from Javascript to C, except certain niches where performance is vital.
  - burfog 8y ago
    I disagree about "better", but... If you like your JavaScript, you can keep your JavaScript. You have no reason to care about WebAssembly. Why would you build a JavaScript imitation on WebAssembly when you can just use JavaScipt? WebAssembly is for the rest of us.
    - abuldauskas 8y ago
      That's the thing though. We are all "us" here. We can all compile whatever we want to WebAssembly, that's the point of WebAssembly. One way of doing things doesn't take away from another.
    - danShumway 8y ago
      You might like a JavaScript-like language but want to get rid of the garbage collector, or work closer to the bare metal than Javascript currently allows. WebAssembly is for everyone.
    - dtf 8y ago
      It's not a JavaScript imitation. This is a JavaScript-like syntax for writing WebAssembly. Other than that, (excepting the closure helper) it's 1-to-1 WebAssembly. Not everyone enjoys writing verbose S-Expressions [1], even if it makes for a good canonical format. If you despise JavaScript so much that you can't bear the thought of something that vaguely looks like JavaScript, then don't worry there are other "skins" for writing WebAssembly [2-4] and it should not be too hard to write your own. Finally, nobody owns WebAssembly. It's for clever people like yourself just as much as it is for dirty JavaScript programmers like me. [1] https://developer.mozilla.org/en-US/docs/WebAssembly/Text_format_to_wasm https://developer.mozilla.org/en-US/docs/WebAssembly/Text_fo... [2] https://github.com/tmcw/wah https://github.com/tmcw/wah [3] https://github.com/serprex/luwa https://github.com/serprex/luwa [4] https://medium.com/cirru-project/webassembly-s-expression-and-cirru-syntax-a556b5c6ea52 https://medium.com/cirru-project/webassembly-s-expression-an...
- konaraddio 8y ago
  > The whole point of WebAssembly was to find some way to get away from JavaScript The goal is to "Define a portable, size- and load-time-efficient binary format to serve as a compilation target which can be compiled to execute at native speed by taking advantage of common hardware capabilities...."[0]. [0] https://webassembly.org/docs/high-level-goals/ https://webassembly.org/docs/high-level-goals/
  - ramses0 8y ago
    WASM is then the new JVM. Birth and Death of Javascript indeed.
    - thrower123 8y ago
      Everything old is new again, and the Wheel of Time turns, and ages come and pass, leaving memories that become legend. Legends fade to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the third age by some, an Age yet to come, an age long past, a virtual machine specification was created in an attempt to achieve the goal of write-once, run everywhere code. The specification was not the beginning. There are neither beginnings or endings to the turning of the Wheel of Time. But it was a beginning.
      - pjmlp 8y ago
        Just like CPUs. In the beginning Assembly became bytecode and CPUs included interpreters via microcode, then everything was supposed to be executed directly by hardware gates, now Assembly has become another form of bytecode and all major CPUs have reverted back to microcode. Same applies to GPUs. Everything old is new again, indeed.
      - kowdermeister 8y ago
        Thanks for bringing some poetry to tech land :)
        deleted 8y ago
        [deleted]
danShumway 8y ago
> Walt also has language extensions IMO this is a good decision. I much prefer a platform with a small API than I can personally extend over a large platform that has specific customization options or lots of extra features that all just "kind of" solve whatever problem I have. Reading this makes me more interested in the project than I was before. One quick recommendation, it was kind of hard to find the documentation for the Webpack free compiler (https://www.npmjs.com/package/walt-compiler https://www.npmjs.com/package/walt-compiler). This is purely anecdotal, but I suspect that at least some of the people who are turned on by having a low-level library that doesn't include Typescript niceties will be turned off by seeing the quick-start immediately say to install Webpack. Might be a good idea to have the compiler documentation inside the wiki alongside the quick-start?

burfog 8y ago

Your project is weird to begin with, and then "knew C already" makes it even weirder. The whole point of WebAssembly was to find some way to get away from JavaScript, and to support languages like C. Here you are, going right back to the JavaScript that we've been trying to escape for the past 23 years. Also, on your page you say that "A competent Front-end engineer should be able to edit WebAssembly as easily as any other systems programmer." The "any other" seems to imply that a "Front-end engineer" is a "systems programmer". This is typically not the case.

abuldauskas 8y ago
Escaping JavaScript is not a perspective shared by all (most?), though. It's has been a weird and interesting project, but that's not really a bad thing is it.
- Touche 8y ago
  You'll have to excuse HN Guy that assumes that every project on GitHub is done to try and take over the world and not because, you know, learning is fun. So keep on doing weird things with your weird and awesome language.
- inferiorhuman 8y ago
  I may be in the minority then: one of the big advantages, for me, of WASM is that I can use not-Javascript in the browser. Some of the issues I have with JS are an artifact of being one of the first things to run in the browser (e.g. atrocious standard library) and some are just baked in poor designs (e.g. implicit type casting, == vs ===). Oh gosh, let's not forget what happens when you try to use map and parseInt together.
  - mr_toad 8y ago
    [‘1’,’2’,’3’,’4’,’5’,’6’,’7’,’8’,’9’,’10’].map(d => parseInt(d)); Returns [1,2,3,4,5,6,7,8,9,10]
    - inferiorhuman 8y ago
      I'd expect your example to return a syntax error as those aren't single or double quotes. Try: ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"].map(parseInt);
      - duckerude 8y ago
        Backticks are used for template literals. Try evaluating `2 + 2 = ${2 + 2}`.
        inferiorhuman 8y ago
        Those weren't backticks (`) either. They were "smart" quotes (’ -- you may need a different font to view the differences more readily ’ vs ').
        rounce 8y ago
        But you understood what they meant right?
    - JimDabell 8y ago
      Sure, but you're putting a workaround in – there really shouldn't be any need for that no-op arrow function. But you do actually need it in order to drop all but the first arguments. This is simple, straightforward, and wrong: ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"].map(parseInt) This doesn't work because map() stuffs a counter into the second argument of parseInt(), which is expecting a radix for its second argument. So the iterations of the map go like this: parseInt("1", 0) parseInt("2", 1) parseInt("3", 2) …and so on, which obviously gives garbage results. JavaScript is littered with these kinds of weird edge cases. Even your example with the workaround isn't 100% reliable, it's browser-dependent – when you have leading zeros in your strings, some browsers will interpret them as octal, and some won't.
kristofferR 8y ago
What a weird argument. C is not "better" than Javascript, it is vastly worse for the vast majority of current Javascript uses - where raw performance is a less important consideration than development time. Javascript is far from perfect, but it has improved by leaps and bounds the last few years. WebAssembly is great, but a variant of Javascript or other high-level languages will continue to dominate web development, not C. People aren't going to "escape" from Javascript to C, except certain niches where performance is vital.
- burfog 8y ago
  I disagree about "better", but... If you like your JavaScript, you can keep your JavaScript. You have no reason to care about WebAssembly. Why would you build a JavaScript imitation on WebAssembly when you can just use JavaScipt? WebAssembly is for the rest of us.
  - abuldauskas 8y ago
    That's the thing though. We are all "us" here. We can all compile whatever we want to WebAssembly, that's the point of WebAssembly. One way of doing things doesn't take away from another.
  - danShumway 8y ago
    You might like a JavaScript-like language but want to get rid of the garbage collector, or work closer to the bare metal than Javascript currently allows. WebAssembly is for everyone.
  - dtf 8y ago
    It's not a JavaScript imitation. This is a JavaScript-like syntax for writing WebAssembly. Other than that, (excepting the closure helper) it's 1-to-1 WebAssembly. Not everyone enjoys writing verbose S-Expressions [1], even if it makes for a good canonical format. If you despise JavaScript so much that you can't bear the thought of something that vaguely looks like JavaScript, then don't worry there are other "skins" for writing WebAssembly [2-4] and it should not be too hard to write your own. Finally, nobody owns WebAssembly. It's for clever people like yourself just as much as it is for dirty JavaScript programmers like me. [1] https://developer.mozilla.org/en-US/docs/WebAssembly/Text_format_to_wasm https://developer.mozilla.org/en-US/docs/WebAssembly/Text_fo... [2] https://github.com/tmcw/wah https://github.com/tmcw/wah [3] https://github.com/serprex/luwa https://github.com/serprex/luwa [4] https://medium.com/cirru-project/webassembly-s-expression-and-cirru-syntax-a556b5c6ea52 https://medium.com/cirru-project/webassembly-s-expression-an...
konaraddio 8y ago
> The whole point of WebAssembly was to find some way to get away from JavaScript The goal is to "Define a portable, size- and load-time-efficient binary format to serve as a compilation target which can be compiled to execute at native speed by taking advantage of common hardware capabilities...."[0]. [0] https://webassembly.org/docs/high-level-goals/ https://webassembly.org/docs/high-level-goals/
- ramses0 8y ago
  WASM is then the new JVM. Birth and Death of Javascript indeed.
  - thrower123 8y ago
    Everything old is new again, and the Wheel of Time turns, and ages come and pass, leaving memories that become legend. Legends fade to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the third age by some, an Age yet to come, an age long past, a virtual machine specification was created in an attempt to achieve the goal of write-once, run everywhere code. The specification was not the beginning. There are neither beginnings or endings to the turning of the Wheel of Time. But it was a beginning.
    - pjmlp 8y ago
      Just like CPUs. In the beginning Assembly became bytecode and CPUs included interpreters via microcode, then everything was supposed to be executed directly by hardware gates, now Assembly has become another form of bytecode and all major CPUs have reverted back to microcode. Same applies to GPUs. Everything old is new again, indeed.
    - kowdermeister 8y ago
      Thanks for bringing some poetry to tech land :)
      - deleted 8y ago
        [deleted]

danShumway 8y ago

> Walt also has language extensions IMO this is a good decision. I much prefer a platform with a small API than I can personally extend over a large platform that has specific customization options or lots of extra features that all just "kind of" solve whatever problem I have. Reading this makes me more interested in the project than I was before. One quick recommendation, it was kind of hard to find the documentation for the Webpack free compiler (https://www.npmjs.com/package/walt-compiler https://www.npmjs.com/package/walt-compiler). This is purely anecdotal, but I suspect that at least some of the people who are turned on by having a low-level library that doesn't include Typescript niceties will be turned off by seeing the quick-start immediately say to install Webpack. Might be a good idea to have the compiler documentation inside the wiki alongside the quick-start?