PTR Changelog 2017-09-25: WebAssembly support
@artch but once they're compiled what do we do with them? Can we just leave the compiled binaries alongside the regular code and expect it to work?
I think my confusion was that previous (I thought) they had to be uploaded to a separate branch, but it looks like that's no longer the case.
@tedivm I lost you here, why they have to be uploaded to a separate branch? They are plain binary files which are uploaded to binary Screeps modules via either in-game IDE, grunt-screeps or Steam client. Like in the example above, you have:
dist/ main.js addTwo.wasm
This corresponds to Screeps modules:
@artch thanks for clarifying. I had misread this-
and thought we were uploading binaries to a separate branch on screeps. What you're saying makes for more sense.
Being inspired by Screeps, I was looking for a scalable, high performance and virtualization-friendly solution for Screeps-like AI environment. The candidates were Lua (provides high performance virtual machine and a simple script language) and WA (extremely high performance + built-in virtualization by design).
I've been in a similar situation recently and when evaluating WA vs Lua I decided for Lua.
WA is definitely a big thing, but in it's current state you are in for a lot of trouble. Even if you ignore security risks - and since this thing is basically still alpha you actually really shouldn't - the issues when trying to get a project done with WA are currently too excessive. Eventually WA will become a reasonable alternative, but that's something far in the future.
The main issue with WA is error handling. Even the best programmer will eventually make a mistake, and at this point you need good debugging and logging to find and fix it. WA makes debugging a nightmare. All tools you are used to from JS debugging will not function, and also all tools you might be used to from C/C++ developing will not function either. You can handle some issues with logging, recompiling and waiting (which is very tedious), but some of the lower-level issues like incorrect memory access, pointer failures, off-by-one errors, all that are a major pain to find and fix when you have zero tools to help you. In the end all you can do is to write extensive test-cases and hope to catch all errors, then spend days debugging those you didn't catch.
And on top of that most JS programmers are not experienced with these kind of bugs, as they simply do not exist (in that way) in JS. Which means that many people will have to learn a completely new language (and all the issues that come with it) first, and in the worst way possible.
Lua was definitely the better choice for my kind of problem. While it is not as fast as native C, it's still much faster than JS and therefore suitable for performance-critical parts. On the other hand debugging and writing code is much simpler, as Lua is much closer to JS than C.