8 ms·

I'm very happy to see the WebIDL proposal replaced with something generalized. The article brings up an interesting point: Webassembly really could enable sea

I'm very happy to see the WebIDL proposal replaced with something generalized. The article brings up an interesting point: Webassembly really could enable seamless cross-language integration in the future. Writing a project in Rust, but really want to use that popular face detector written in Python? And maybe the niche language tokenizer written in PHP? And sprinkle ffmpeg on top, without the hassle of target-compatible compilation and worrying about use after free vulnerabilities? No problem use one of the many WASM runtimes popping up (like [1], [2]) and combine all those libraries by using their pre-compiled WASM packages distributed on a package repo like WAPM [2], with auto-generated bindings that provide a decent API from your host language. Sounds too good to be true? Probably, and there are plenty of issues to solve. But it sounds like a future where we could prevent a lot of the re-writes and duplication across the open source world by just tapping into the ecosystems of other languages. [1] https://wapm.io/ https://wapm.io/ [2] https://github.com/CraneStation/wasmtime https://github.com/CraneStation/wasmtime [2] https://wapm.io/ https://wapm.io/

wahern 7y ago
JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language". Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they didn't, and WASM won't.) At best you'll get a Rust'ish WASM, Python'ish WASM, PHP'ish WASM, etc. And all of those will feel like a cousin to JavaScript, just as anything on the JVM feels similar to Java, on Parrot feels similar to Perl 6, and on the CLR feels similar to C#. WASM's choice of data structures, control flow, and data representations will be strongly influenced by the requirements of the major JavaScript engines (in Firefox, Chrome, and maybe WebKit). This is already the case when it comes to control flow semantics.
- k__ 7y ago
  Could it be that JVM and CLR were technically correct, but policy wrong?
  - pjmlp 7y ago
    It is more politics than anything else, with WASM being the new cool kid on the block.
    - Rusky 7y ago
      You keep saying this, but WASM has some very specific technical differences from these previous VMs that make a huge difference.
      - thesuperbigfrog 7y ago
        Would you please share the "very specific technical differences"? As a long-time JVM user, I am curious about WASM and how it compares to the JVM and CLR.
        k__ 7y ago
        As far as I know, WASM was thought of as a compilation target for languages like C and Rust, which are quite different from Java and C#. That alone should make WASM quite different from the JVM, no?
        pjmlp 7y ago
        https://github.com/oracle/graal https://github.com/oracle/graal The evolution from MaximeVM, which is now increasingly being integrated into OpenJDK as part of project Metropolis. As for the CLR, it supports VB.NET, C++ and C# since day one, including a Common Language Specification and Common Type System. Then alongside its history got COBOL, Eiffel, F#, Ruby, Python, Nermele, Clojure,.... IBM and UNISYS mainframes language environments support a mix of COBOL, C, C++, Fortran, RPG, NEWP, also with a common type system for interoperability. While UNISYS documents are a bit hard to come by, IBM ones are available as RedBooks.
        Rusky 7y ago
        Again, you keep bringing these up, by they are not the same thing as WASM. Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs; it requires per-language support for them and works in terms of program source. The CLR's C++ support is nothing like WebAssembly C++- you either FFI to native code, bypassing the VM, or you compile a limited subset of C++ to unverified bytecode- and the latter doesn't support newer language standards and is being phased out. WebAssembly solves both of these problems- existing compilers for any unmodified language can target its standard binary interchange format the same way they would target a hardware architecture, and run within its sandbox. WebAssembly doesn't need to add support for them, or know anything about their source form.
- RussianCow 7y ago
  I mostly agree with you, but it's important to point out that the big difference between WASM and the runtimes you mentioned is that WASM works in the browser, so you get out-of-the-box support for the world's biggest app platform. That's something that no other cross-platform runtime has achieved in any meaningful way, as far as I know.
  - mrec 7y ago
    Java used to work in the browser a quarter-century ago, albeit not very well. Even .NET sort of worked in the browser for both the people who enabled Silverlight. I do believe WASM is different, in a good way, but not just because it works in a browser.
    - nerdponx 7y ago
      This probably a good subject for a separate thread, but I do wonder why JVM-in-browser failed so hard. I know there were "security issues" but surely those weren't any worse than the JS security issues we have today?
      - mrec 7y ago
        Steve Klabnik wrote a blog post around this last year. More challenging the "isn't WASM just another Java?" take, but I think still relevant to your question. https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...
        nerdponx 7y ago
        That immediately clarifies the difference. Thank you.
      - repolfx 7y ago
        It didn't fail that hard. It was pretty widely used, but the JRE was a large and not very fast runtime back then. It got better over time but the browser makers got pretty determined to kill off any competing platforms to HTML under the guise of security.
- asdkhadsj 7y ago
  Ah, there it is, the JVM discussion in any WASM thread. I kid. On topic though, I'll be curious to see how bad it really is. The demo video showed code that ended up looking and behaving like normal Rust code. Maybe you'll end up with some oddities like Rust enums not being supported, but w/e. At the end of the day, I don't need to make weird and often gross C bindings in my Rust or Go code. Is that not a huge win? But you're right, maybe this will go the way of the JVM and no one will care. Or maybe not. Does it matter? edit: And I should add, maybe I keep forgetting where my well supported JVM Python <-> Rust or Go <-> Rust bridge is. Maybe someone can remind me, because I've not seen it.
  - wahern 7y ago
    I don't doubt that the ubiquity of WASM environments will result in more software targeting the environment. My contention is with the notion that we'll all be seamlessly mixing different languages. Far more likely is that WASM influences the evolution of various languages, resulting in homogenization of semantics. C++ is already going in this direction--preferring some proposals over others because of easier interoperability with WASM's constraints. Other languages with irreconcilably distinct semantics, such as Go's goroutines, are likely doomed to be second-class citizens as compared to Rust or C++. Languages like Python and PHP are likely to see either major refactoring of their engines, or else see the rise of alternative implementations that are more performant in WASM environments and offer more seamless data interchange.
    - marcosdumay 7y ago
      Goroutines only require a slightly fat runtime. Haskell uses basically the same mechanism, with C interoperability, and all it takes is starting (and optionally, stopping) the runtime.
      - wahern 7y ago
        It's not having a runtime that's the problem, it's limitations in WASM's control flow constructs: https://github.com/WebAssembly/design/issues/796#issuecomment-401310366 https://github.com/WebAssembly/design/issues/796#issuecommen... And WASM has this limitation as a consequence of limitations in the V8 and SpiderMonkey engines. See http://troubles.md/posts/why-do-we-need-the-relooper-algorithm-again http://troubles.md/posts/why-do-we-need-the-relooper-algorit... and https://news.ycombinator.com/item?id=19997091 https://news.ycombinator.com/item?id=19997091 And those engines have those limitations because they're a reasonable design tradeoff in the context of executing JavaScript. I think even if WASM gets a limited goto sufficient to resolve the most problematic performance issues, languages like Go that use more sophisticated control flow constructs (e.g. stackful coroutines) will always be at a disadvantage relative to C or Rust when it comes to WASM as absence of other various low-level constructs (e.g. ability to directly handle page faults) will incur higher relative penalties. The same thing could be said about Rust's new async/await--WASM will compound the costs of the additional indirect branching in async-compiled functions (not to mention the greater number of function invocations, which is at least 2x even if a function never defers). That said, I don't think anybody uses Go for the insane performance, so as long as the performance impact isn't too severe (and limited goto support will help tremendously) it shouldn't be much of an issue. OTOH, these sorts of tradeoffs are why "native" code will always have a significant place. Especially as the wall we've hit in terms of single-threaded performance begins to be felt more widely.
- kodablah 7y ago
  > At best you'll get a Rust'ish WASM, Python'ish WASM, PHP'ish WASM, etc I agree with the latter two due to runtime uniqueness, but not so sure it holds for Rust. Since C FFI has become the defacto WASM standard (with higher level interop coming as the article suggests), some low-overhead langs like Rust can be reasonably used elsewhere via WASM (though in most cases, you'd use them as native libs if you had the option). Essentially it comes down to two things: How much of the WASM conformance is language-specific at compile time (e.g. for Go, stack resumption is manually built causing bloated WASM), and how much overhead does WASM interop cause at runtime (e.g. can it use the string interface type instead of converting to what it considers a string in local memory and what are the tradeoffs of each approach). If your language has a low WASM impedance mismatch at compile time and runtime, like Rust, it is a decent candidate for a WASM target. If your runtime has a low WASM impedance mismatch (e.g. the browser, native, and to some extent the JVM), it is a decent candidate to run that other decent-candidate WASM code without a huge overhead. I've run Rust on the JVM [0], C in the browser, etc with decent performance because of those characteristics. 0 - https://github.com/cretz/asmble/tree/master/examples/rust-regex https://github.com/cretz/asmble/tree/master/examples/rust-re...
- bcheung 7y ago
  I'm a full time React developer but I would much rather see the CLR than WASM as a universal platform target. The CLR already supports a larger variety of programming languages from dynamically typed languages like Ruby and Python, to C#, to F# for functional style programming. It already exists with a rich ecosystem of libraries. The tools to generate CIL opcodes are pretty good and the developer tools with Intellisense are pretty good as well. It has good packaging support with assemblies. And you can already compile .NET code to WASM using Blazor. And with .NET already running on Linux, Win, Mac, iOS, Android, and IOT devices, I don't really see targeting WASM adding anything that doesn't already exist.
  - deleted 7y ago
    [deleted]
  - guhidalg 7y ago
    Yes but like the parent poster said, all of the CLR features are really to serve one language: C#. All other languages primarily targeting the CLR must be understood in the context of “how would you express this thing in C# and how will a C# client interact with your assembly”. Thus, WASM will forever be tied to javascript and all other languages will need to deal with questions of “how would I express this in JavaScript”.
    - bcheung 7y ago
      C# is the largest language for sure but it was designed for multiple languages from the start. There are things you can do in CIL and other languages that you can't do in C# even. Functional languages and pattern matching can be expressed quite well in .NET which aren't in C# (at least not yet fully). I think the statement that the CLR ties you to C# is not justified. Can you elaborate why you think this is the case? Also, WASM is not tied to JavaScript. You can't even compile JavaScript to WASM because it doesn't support the necessary primitives. In fact other languages that are completely different than JavaScript compile to WASM much easier.
      - wahern 7y ago
- coldtea 7y ago
  >JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language". Java tied a whole ecosystem and was a pain to connect to anything outside, Parrot is a perennially incomplete half-arsed experiment, and C# has been historically tied to the MS ecosystem (and is also a pain to link to from outside). The promise here is that the new system would have cross platform, cross vendor support (e.g. MS, Apple, Google, Mozilla), and that it wont be a pain to link to from, say, C or Rust or Python. >WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. Doesn't need to. It's enough that it solves the same issue linking to a C library with bindings does, but without re-compilation, with a sandbox, and an easier interface. I'd like to use e.g. something like Pillow or a numeric lib, etc, in WASM from languages outside Python...
- chromatic 7y ago
  Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they didn't, and WASM won't.) I endorse this point of view, from hard-won experience. (Also: memory model. Always memory model.)
sunfish 7y ago
Besides the technology questions, there are also non-technical considerations too. Who do you want governing the package repo you host all your code in?
pjmlp 7y ago
You mean like I would use IronPython, with the codecs coded in C++/CLI, ML analysis in F# and the UI in XAML/C# all on top of the CLR?
ori_b 7y ago
> Webassembly really could enable seamless cross-language integration in the future. > Writing a project in Rust, but really want to use that popular face detector written in Python? So, how exactly do you magically enforce affine type semantics in the data you pass to wasm-python, and transparently forward calls to the bound __call__ method of python objects? The calls are easy, even today. Semantics are hard.
- cesarb 7y ago
  > So, how exactly do you magically enforce affine type semantics in the data you pass to wasm-python In Rust, calling foreign functions is considered unsafe, precisely for that reason: once you leave the boundaries of a single language, the compiler can no longer enforce these invariants for you.
  - ori_b 7y ago
    So, the solution is to make more or less every foreign call unsafe. That's pretty close to the state of the art without wasm. I'm not sure how satisfactory that is, especially when it is fairly idiomatic for many calls in garbage collected languages to both keep and return a reference (eg, builder pattern), which may lead to rust calling a destructor where the other language doesn't expect it.
  - the_duke 7y ago
    If I understand the proposal correctly, it should actually be possible to auto-generate safe glue code. These interface types can describe, eg, how to map a Python String or list to a generic representation (pointer + length), and Rust can then take this generic form and map it into a valid Rust string safely - with the intermediate guarantees verified by the WASM runtime.

wahern 7y ago

JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language". Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they didn't, and WASM won't.) At best you'll get a Rust'ish WASM, Python'ish WASM, PHP'ish WASM, etc. And all of those will feel like a cousin to JavaScript, just as anything on the JVM feels similar to Java, on Parrot feels similar to Perl 6, and on the CLR feels similar to C#. WASM's choice of data structures, control flow, and data representations will be strongly influenced by the requirements of the major JavaScript engines (in Firefox, Chrome, and maybe WebKit). This is already the case when it comes to control flow semantics.

k__ 7y ago
Could it be that JVM and CLR were technically correct, but policy wrong?
- pjmlp 7y ago
  It is more politics than anything else, with WASM being the new cool kid on the block.
  - Rusky 7y ago
    You keep saying this, but WASM has some very specific technical differences from these previous VMs that make a huge difference.
    - thesuperbigfrog 7y ago
      Would you please share the "very specific technical differences"? As a long-time JVM user, I am curious about WASM and how it compares to the JVM and CLR.
      - k__ 7y ago
        As far as I know, WASM was thought of as a compilation target for languages like C and Rust, which are quite different from Java and C#. That alone should make WASM quite different from the JVM, no?
        pjmlp 7y ago
        https://github.com/oracle/graal https://github.com/oracle/graal The evolution from MaximeVM, which is now increasingly being integrated into OpenJDK as part of project Metropolis. As for the CLR, it supports VB.NET, C++ and C# since day one, including a Common Language Specification and Common Type System. Then alongside its history got COBOL, Eiffel, F#, Ruby, Python, Nermele, Clojure,.... IBM and UNISYS mainframes language environments support a mix of COBOL, C, C++, Fortran, RPG, NEWP, also with a common type system for interoperability. While UNISYS documents are a bit hard to come by, IBM ones are available as RedBooks.
        Rusky 7y ago
        Again, you keep bringing these up, by they are not the same thing as WASM. Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs; it requires per-language support for them and works in terms of program source. The CLR's C++ support is nothing like WebAssembly C++- you either FFI to native code, bypassing the VM, or you compile a limited subset of C++ to unverified bytecode- and the latter doesn't support newer language standards and is being phased out. WebAssembly solves both of these problems- existing compilers for any unmodified language can target its standard binary interchange format the same way they would target a hardware architecture, and run within its sandbox. WebAssembly doesn't need to add support for them, or know anything about their source form.
RussianCow 7y ago
I mostly agree with you, but it's important to point out that the big difference between WASM and the runtimes you mentioned is that WASM works in the browser, so you get out-of-the-box support for the world's biggest app platform. That's something that no other cross-platform runtime has achieved in any meaningful way, as far as I know.
- mrec 7y ago
  Java used to work in the browser a quarter-century ago, albeit not very well. Even .NET sort of worked in the browser for both the people who enabled Silverlight. I do believe WASM is different, in a good way, but not just because it works in a browser.
  - nerdponx 7y ago
    This probably a good subject for a separate thread, but I do wonder why JVM-in-browser failed so hard. I know there were "security issues" but surely those weren't any worse than the JS security issues we have today?
    - mrec 7y ago
      Steve Klabnik wrote a blog post around this last year. More challenging the "isn't WASM just another Java?" take, but I think still relevant to your question. https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...
      - nerdponx 7y ago
        That immediately clarifies the difference. Thank you.
    - repolfx 7y ago
      It didn't fail that hard. It was pretty widely used, but the JRE was a large and not very fast runtime back then. It got better over time but the browser makers got pretty determined to kill off any competing platforms to HTML under the guise of security.
asdkhadsj 7y ago
Ah, there it is, the JVM discussion in any WASM thread. I kid. On topic though, I'll be curious to see how bad it really is. The demo video showed code that ended up looking and behaving like normal Rust code. Maybe you'll end up with some oddities like Rust enums not being supported, but w/e. At the end of the day, I don't need to make weird and often gross C bindings in my Rust or Go code. Is that not a huge win? But you're right, maybe this will go the way of the JVM and no one will care. Or maybe not. Does it matter? edit: And I should add, maybe I keep forgetting where my well supported JVM Python <-> Rust or Go <-> Rust bridge is. Maybe someone can remind me, because I've not seen it.
- wahern 7y ago
  I don't doubt that the ubiquity of WASM environments will result in more software targeting the environment. My contention is with the notion that we'll all be seamlessly mixing different languages. Far more likely is that WASM influences the evolution of various languages, resulting in homogenization of semantics. C++ is already going in this direction--preferring some proposals over others because of easier interoperability with WASM's constraints. Other languages with irreconcilably distinct semantics, such as Go's goroutines, are likely doomed to be second-class citizens as compared to Rust or C++. Languages like Python and PHP are likely to see either major refactoring of their engines, or else see the rise of alternative implementations that are more performant in WASM environments and offer more seamless data interchange.
  - marcosdumay 7y ago
    Goroutines only require a slightly fat runtime. Haskell uses basically the same mechanism, with C interoperability, and all it takes is starting (and optionally, stopping) the runtime.
    - wahern 7y ago
      It's not having a runtime that's the problem, it's limitations in WASM's control flow constructs: https://github.com/WebAssembly/design/issues/796#issuecomment-401310366 https://github.com/WebAssembly/design/issues/796#issuecommen... And WASM has this limitation as a consequence of limitations in the V8 and SpiderMonkey engines. See http://troubles.md/posts/why-do-we-need-the-relooper-algorithm-again http://troubles.md/posts/why-do-we-need-the-relooper-algorit... and https://news.ycombinator.com/item?id=19997091 https://news.ycombinator.com/item?id=19997091 And those engines have those limitations because they're a reasonable design tradeoff in the context of executing JavaScript. I think even if WASM gets a limited goto sufficient to resolve the most problematic performance issues, languages like Go that use more sophisticated control flow constructs (e.g. stackful coroutines) will always be at a disadvantage relative to C or Rust when it comes to WASM as absence of other various low-level constructs (e.g. ability to directly handle page faults) will incur higher relative penalties. The same thing could be said about Rust's new async/await--WASM will compound the costs of the additional indirect branching in async-compiled functions (not to mention the greater number of function invocations, which is at least 2x even if a function never defers). That said, I don't think anybody uses Go for the insane performance, so as long as the performance impact isn't too severe (and limited goto support will help tremendously) it shouldn't be much of an issue. OTOH, these sorts of tradeoffs are why "native" code will always have a significant place. Especially as the wall we've hit in terms of single-threaded performance begins to be felt more widely.
kodablah 7y ago
> At best you'll get a Rust'ish WASM, Python'ish WASM, PHP'ish WASM, etc I agree with the latter two due to runtime uniqueness, but not so sure it holds for Rust. Since C FFI has become the defacto WASM standard (with higher level interop coming as the article suggests), some low-overhead langs like Rust can be reasonably used elsewhere via WASM (though in most cases, you'd use them as native libs if you had the option). Essentially it comes down to two things: How much of the WASM conformance is language-specific at compile time (e.g. for Go, stack resumption is manually built causing bloated WASM), and how much overhead does WASM interop cause at runtime (e.g. can it use the string interface type instead of converting to what it considers a string in local memory and what are the tradeoffs of each approach). If your language has a low WASM impedance mismatch at compile time and runtime, like Rust, it is a decent candidate for a WASM target. If your runtime has a low WASM impedance mismatch (e.g. the browser, native, and to some extent the JVM), it is a decent candidate to run that other decent-candidate WASM code without a huge overhead. I've run Rust on the JVM [0], C in the browser, etc with decent performance because of those characteristics. 0 - https://github.com/cretz/asmble/tree/master/examples/rust-regex https://github.com/cretz/asmble/tree/master/examples/rust-re...
bcheung 7y ago
I'm a full time React developer but I would much rather see the CLR than WASM as a universal platform target. The CLR already supports a larger variety of programming languages from dynamically typed languages like Ruby and Python, to C#, to F# for functional style programming. It already exists with a rich ecosystem of libraries. The tools to generate CIL opcodes are pretty good and the developer tools with Intellisense are pretty good as well. It has good packaging support with assemblies. And you can already compile .NET code to WASM using Blazor. And with .NET already running on Linux, Win, Mac, iOS, Android, and IOT devices, I don't really see targeting WASM adding anything that doesn't already exist.
- deleted 7y ago
  [deleted]
- guhidalg 7y ago
  Yes but like the parent poster said, all of the CLR features are really to serve one language: C#. All other languages primarily targeting the CLR must be understood in the context of “how would you express this thing in C# and how will a C# client interact with your assembly”. Thus, WASM will forever be tied to javascript and all other languages will need to deal with questions of “how would I express this in JavaScript”.
  - bcheung 7y ago
    C# is the largest language for sure but it was designed for multiple languages from the start. There are things you can do in CIL and other languages that you can't do in C# even. Functional languages and pattern matching can be expressed quite well in .NET which aren't in C# (at least not yet fully). I think the statement that the CLR ties you to C# is not justified. Can you elaborate why you think this is the case? Also, WASM is not tied to JavaScript. You can't even compile JavaScript to WASM because it doesn't support the necessary primitives. In fact other languages that are completely different than JavaScript compile to WASM much easier.
    - wahern 7y ago
coldtea 7y ago
>JVM (Java), Parrot (Perl 6 VM) and CLR (C#) shipped easy, multi-language environments over a decade ago. For some definitions of "easy" and "multi-language". Java tied a whole ecosystem and was a pain to connect to anything outside, Parrot is a perennially incomplete half-arsed experiment, and C# has been historically tied to the MS ecosystem (and is also a pain to link to from outside). The promise here is that the new system would have cross platform, cross vendor support (e.g. MS, Apple, Google, Mozilla), and that it wont be a pain to link to from, say, C or Rust or Python. >WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. Doesn't need to. It's enough that it solves the same issue linking to a C library with bindings does, but without re-compilation, with a sandbox, and an easier interface. I'd like to use e.g. something like Pillow or a numeric lib, etc, in WASM from languages outside Python...
chromatic 7y ago
Different programming languages exist for many reasons, only one of which is syntax. Many of these reasons relate to data structures and runtime control flow. WASM won't be able to "solve" these issue any better than the JVM, Parrot, or CLR did. (Spoiler: they didn't, and WASM won't.) I endorse this point of view, from hard-won experience. (Also: memory model. Always memory model.)

sunfish 7y ago

Besides the technology questions, there are also non-technical considerations too. Who do you want governing the package repo you host all your code in?

pjmlp 7y ago

You mean like I would use IronPython, with the codecs coded in C++/CLI, ML analysis in F# and the UI in XAML/C# all on top of the CLR?

ori_b 7y ago

> Webassembly really could enable seamless cross-language integration in the future. > Writing a project in Rust, but really want to use that popular face detector written in Python? So, how exactly do you magically enforce affine type semantics in the data you pass to wasm-python, and transparently forward calls to the bound __call__ method of python objects? The calls are easy, even today. Semantics are hard.

cesarb 7y ago
> So, how exactly do you magically enforce affine type semantics in the data you pass to wasm-python In Rust, calling foreign functions is considered unsafe, precisely for that reason: once you leave the boundaries of a single language, the compiler can no longer enforce these invariants for you.
- ori_b 7y ago
  So, the solution is to make more or less every foreign call unsafe. That's pretty close to the state of the art without wasm. I'm not sure how satisfactory that is, especially when it is fairly idiomatic for many calls in garbage collected languages to both keep and return a reference (eg, builder pattern), which may lead to rust calling a destructor where the other language doesn't expect it.
- the_duke 7y ago
  If I understand the proposal correctly, it should actually be possible to auto-generate safe glue code. These interface types can describe, eg, how to map a Python String or list to a generic representation (pointer + length), and Rust can then take this generic form and map it into a valid Rust string safely - with the intermediate guarantees verified by the WASM runtime.