4 ms·

I have to say I am pretty excited about WebAssembly. I've been through many programming languages. C# might be my favourite and F# always seemed like it would

I have to say I am pretty excited about WebAssembly. I've been through many programming languages. C# might be my favourite and F# always seemed like it would be if I took the time to learn it properly but for quite a few years now, JS has simply had such gravitational pull that I felt like I had to go with it. And I have to say, I've learned to not only like but to love it. Save for the mutable data structures that it supplies per default, it offers solid functional programming features and the culture embraces those. Still, there are times where I wish I could use something else. NPM features quite a few packages written in other languages, with JS "binaries" available which I think is pretty neat. To me, packages seem like a much nicer place to choose language rather than, say, per microservice. A parser might be much cleaner in some pure functional language while some I/O library might work better in something else. But there is still only a subset of languages that compile to JS and the quality varies. But with LLVM supporting WebAssembly, I can see a future where it truly becomes the global binary format. Which would allow you to either write a combination of desktop, mobile and web apps (plus backend) in any language of your choice. Or, easliy write different packages in different languages and combine them into one app.

pjmlp 9y ago
Bytecode formats as portable binaries have always been a thing on the mainframe world all the way back to the 60's, it has just taken quite a few decades to become commodity across mobile, desktop and web worlds.
- Koshkin 9y ago
  Googling this only turns up Java...
  - pjmlp 9y ago
    Then you need to improve your Google-fu. Burroughs, Xerox PARC systems, ETHZ Lilith, Pascal UCSD, IBM TIMI, IBM Language Environment, ...
    - puzzle 9y ago
      Also Oberon SDE...
      - kristianp 9y ago
        Is this it? https://hokstad.com/semantic-dictionary-encoding https://hokstad.com/semantic-dictionary-encoding
        puzzle 9y ago
        Indeed. AKA slim binaries.
- imtringued 9y ago
  Even GPU drivers compile shaders to the respective internal architecture of the GPU. Only desktops, laptops and commodity servers have managed to get stuck with x86 backwards compatiblity. It's probably rooted in microsoft's dependence on intel but nowadays even microsoft has a cross architecture SDK (UWP).
kodablah 9y ago
> Or, easliy write different packages in different languages and combine them into one app. Just because the binary format can be shared doesn't mean code easily can. There's a tradeoff between requiring lots of glue or sharing a common lib across the langs. Either way, in WASM's current state, only the raw memory is shared and the only types are numeric primitives that can be used to address that memory. How each language lays out, for example, strings may be incompatible and most of the time where I've had to combine WASM libs for things like strings, there is a fallback to C-style (null-term'd or passing the length around). So, while the common binary format will help open new architectures to existing langs, combining code from different langs still requires manual work and may be underperforming due to requiring they speak to each other in the lowest common denominator of raw byte arrays. Maybe some group will step up and federate a new libc for the WASM generation (even if there's no code and it only defines memory layouts). Even other proposals (GC w/ records/structs, host binding, ref types, etc) that bring higher level features don't necessarily solve interoperability issues.
- skybrian 9y ago
  In practice, most WASM languages are going to want good interop with JavaScript, so if nothing else is done, I expect that would become the standard for foreign functions, much like C FFI is on the desktop. For example, look at what Rust is doing [1]. For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border? JavaScript strings aren't perfect (I prefer how Go does it) but they're usually good enough. [1] https://github.com/koute/stdweb https://github.com/koute/stdweb
  - kodablah 9y ago
    > For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border? This doesn't really exist unless you mean they need to not operate on the strings in their own memory and instead make a bunch of JS calls to operate on strings. That has overhead. Otherwise you have to use some approach to get the string to an array buffer (e.g. TextEncoder, charCodeAt, etc) and even though they are probably utf-8 internally, the step still exists to get them to WASM memory. For the GP's post about combining languages, it's no fun to do all of this to use a WASM Rust string in WASM Go (this is what I meant about "lowest common denominator").

pjmlp 9y ago

Bytecode formats as portable binaries have always been a thing on the mainframe world all the way back to the 60's, it has just taken quite a few decades to become commodity across mobile, desktop and web worlds.

Koshkin 9y ago
Googling this only turns up Java...
- pjmlp 9y ago
  Then you need to improve your Google-fu. Burroughs, Xerox PARC systems, ETHZ Lilith, Pascal UCSD, IBM TIMI, IBM Language Environment, ...
  - puzzle 9y ago
    Also Oberon SDE...
    - kristianp 9y ago
      Is this it? https://hokstad.com/semantic-dictionary-encoding https://hokstad.com/semantic-dictionary-encoding
      - puzzle 9y ago
        Indeed. AKA slim binaries.
imtringued 9y ago
Even GPU drivers compile shaders to the respective internal architecture of the GPU. Only desktops, laptops and commodity servers have managed to get stuck with x86 backwards compatiblity. It's probably rooted in microsoft's dependence on intel but nowadays even microsoft has a cross architecture SDK (UWP).

kodablah 9y ago

> Or, easliy write different packages in different languages and combine them into one app. Just because the binary format can be shared doesn't mean code easily can. There's a tradeoff between requiring lots of glue or sharing a common lib across the langs. Either way, in WASM's current state, only the raw memory is shared and the only types are numeric primitives that can be used to address that memory. How each language lays out, for example, strings may be incompatible and most of the time where I've had to combine WASM libs for things like strings, there is a fallback to C-style (null-term'd or passing the length around). So, while the common binary format will help open new architectures to existing langs, combining code from different langs still requires manual work and may be underperforming due to requiring they speak to each other in the lowest common denominator of raw byte arrays. Maybe some group will step up and federate a new libc for the WASM generation (even if there's no code and it only defines memory layouts). Even other proposals (GC w/ records/structs, host binding, ref types, etc) that bring higher level features don't necessarily solve interoperability issues.

skybrian 9y ago
In practice, most WASM languages are going to want good interop with JavaScript, so if nothing else is done, I expect that would become the standard for foreign functions, much like C FFI is on the desktop. For example, look at what Rust is doing [1]. For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border? JavaScript strings aren't perfect (I prefer how Go does it) but they're usually good enough. [1] https://github.com/koute/stdweb https://github.com/koute/stdweb
- kodablah 9y ago
  > For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border? This doesn't really exist unless you mean they need to not operate on the strings in their own memory and instead make a bunch of JS calls to operate on strings. That has overhead. Otherwise you have to use some approach to get the string to an array buffer (e.g. TextEncoder, charCodeAt, etc) and even though they are probably utf-8 internally, the step still exists to get them to WASM memory. For the GP's post about combining languages, it's no fun to do all of this to use a WASM Rust string in WASM Go (this is what I meant about "lowest common denominator").