5 ms·

This is exciting. I think WASM is an example of a thin waist [1] with its garbage collector and N+M rather than N×M. (N languages + M virtual machines + G garb

This is exciting. I think WASM is an example of a thin waist [1] with its garbage collector and N+M rather than N×M. (N languages + M virtual machines + G garbage collectors). That's a mature garbage collector in V8. I was curious if there was a WASM to JVM and it seems there is one on GitHub, I haven't used it I was just curious because the JVM is a mature (and parallel) garbage collector. Now I'm excited for WASM Threads for true parallelism and not just IO parallelism because I didn't think WASMGC would come out so soon. The opportunity to solve async and parallelism and garbage collection EFFECTIVELY would strengthen WASM and not be a source of confusion or difficulty for developers. I think that's why WASI is so important, a chance to define an API as stable as POSIX. 1: https://www.oilshell.org/blog/2022/02/diagrams.html https://www.oilshell.org/blog/2022/02/diagrams.html 2: https://github.com/cretz/asmble https://github.com/cretz/asmble

pjmlp 3y ago
Following CLR footsteps, 22 years later. > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. From https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d...
- quickthrower2 3y ago
  Where is my Haskell.NET? Dammit!
  - delta_p_delta_x 3y ago
    F#: https://learn.microsoft.com/en-sg/dotnet/fsharp/what-is-fsharp https://learn.microsoft.com/en-sg/dotnet/fsharp/what-is-fsha... EDIT: Yes, F# is an ML-style language. I was answering the spirit of the question, which was 'statically-typed functional-first programming language running on the .NET CLR'.
    - masklinn 3y ago
      F# is ocaml.net not haskell.net
- debugnik 3y ago
  If only the CLR had followed CLR footsteps as well, but they didn't even try after the DLR. Most non-Roslyn languages can barely interact with modern C# or the newer build configurations; even F# is playing catch-up and they're part of the official toolchain.
  - pjmlp 3y ago
    That is the sin of guest languages, that is why C rules on UNIX, JavaScript on Web, Java on the JVM, C# on the CLR, .... Every guest language means additional IDE plugins with platform knowledge, since most communities want idiomatic libraries, an ecosystem on top of the ecosystem, as the actual platform is only implemented in a main "systems" language, mastering it is required anyway for all the leaky abstractions on the platform, additional build toolchains,... In the end, each polyglot platform achieves a global maximum of main language, and possibly a winner among all guest languages, even if it takes a couple of years with projects fading away until this happens. It sucks, however so it is the outcome of human nature attention span, and not being able to keep momentum for all languages across the whole lifetime of a given platform.
    - HappMacDonald 3y ago
      It feels to me a little bit like how geographic regions wind up working out dominant spoken/written languages. The guest languages are like relying on (human or machine) speech/writing translation services to communicate with folks who only know the local lingua franca. That added friction hobbles the minority languages. Perhaps AI will aid in greatly reducing these issues over time (and I say this because large language translation models and text to speech + speech to text are finally reaching professional human quality while running on local hardware today). But I can't think of any other good method to hold back the floodgates of people being forced to choose between their mother tongue (with its corpus of invaluable baked in stories and perspectives) and being understood by others.
    - no_wizard 3y ago
      I think Kotlin is slowly eclipsing Java on the JVM. Its not majority yet but most new projects or major refactors I've seen are either 100% Kotlin or majority Kotlin. I would not be surprised if Kotlin takes a majority share eventually
- titzer 3y ago
  I don't really know where to place this comment. Multi-language systems existed before, therefore Wasm should not, because it's already been done? It's interesting that none of the languages that you list made .NET a primary target and have all either bit-rotted unofficial ports or sunsetted their mainline support. It's hard to say whether languages that now target Wasm will suffer the same fate, since that depends on level of maintenance that each project allocates to particular targets. Still, I don't really get your point.
  - pjmlp 3y ago
    The usual amazement as if WASM was the first at anything...
    - tambourine_man 3y ago
      Being first rarely matters. Good execution at the right time is the crucial part.
      - mtsr 3y ago
        And maybe not being the start of another MS embrace-extend-extinguish ploy.
    - refulgentis 3y ago
      People know VMs existed before WASM
- saila 3y ago
  I was just looking at the status of IronPython, and it's on Python 3.4, which has been end-of-life for nearly five years. I'm not sure that indicates practical usability for most developers. Only C#, VB, and maybe F# actually seem like a safe choice on .NET. (PowerShell too, but that's a different use case.) So, just because something has been, or can be, done "in theory" doesn't mean all that much. Unless you were intending this as a criticism of .NET? I could see WASM actually pulling this off.
  - ejiblabahaba 3y ago
    IronPython is indeed quite a pain to work with, and for a lot of reasons beyond the age. For instance, you don't get numpy or any dependencies that themselves depend on quirks of CPython. The alternative is PythonNET, which executes python in CPython context, but provides nearly the same interoperability* with CLR assemblies. There's many devils in the details of that asterisk, and I'm frankly not knowledgeable enough to explain them; but in my experience, things work well enough that I'm satisfied with the integration provided.
kaba0 3y ago
GraalVM can run WASM executables: https://www.graalvm.org/latest/reference-manual/wasm/ https://www.graalvm.org/latest/reference-manual/wasm/
chriswarbo 3y ago
> Now I'm excited for WASM Threads for true parallelism Pedantic: threads are concurrent, not necessarily parallel. It's weird to see them called "true parallelism". I assume you mean in comparison to coroutines, but those are sequential (their execution order may be arbitrary, but we can rely on them not being concurrent). If wasm adopts threads that would be another unfortunate WorseIsBetter situation, given that threads are probably the worst model of concurrency we've ever devised (other than concurrent COMEFROM)!
- titzer 3y ago
  > If wasm adopts threads that would be another unfortunate WorseIsBetter situation, given that threads are probably the worst model of concurrency we've ever devised (other than concurrent COMEFROM)! Like it or not, threads are here to stay. Threads with shared mutable memory are the abstraction that multi-processor systems give software. They are not a software invention (anymore, as they might have been considered in the uniprocessor era). A key goal of Wasm is to be a portable (and safe!) abstraction over hardware. Thus exposing extremely pervasive hardware abstractions like threads is well within its mission. Doing so safely has meant careful design and specification that captures what hardware gives for memory models without forcing a new programming model or undue burden on languages, toolchains, or runtimes. Given that there are literally billions of lines of software that use threads, hardware actually implements threads, and the entire stack is driven to optimize threads, it would indeed be a bold move to impose a different abstraction at the Wasm level. An abstraction that would incidentally be immediately used to emulate threads. That's a real layering screwup--abstraction inversion. Also, I think your pedantry is unwarranted and a distraction. Many people accept the claim that threads are "true parallelism" and would consider cooperative (or even green) threading systems to be "not what we meant when we said threads". It's just a red herring to go off and discuss technicalities when the context is clearly Wasm exposing hardware threads.
  - Kinrany 3y ago
    > An abstraction that would incidentally be immediately used to emulate threads. That would be a win if performance was the same!
kodablah 3y ago
> I was curious if there was a WASM to JVM and it seems there is one on GitHub [...] https://github.com/cretz/asmble https://github.com/cretz/asmble While it works well, this was mostly a fun project for me and I no longer really maintain it. I hope that the ideas and explanations of how I mapped WASM IR to JVM bytecodes helps whoever does build this in a more official capacity. I don't have any plans to support WASM GC currently.
apatheticonion 3y ago
> Now I'm excited for WASM Threads for true parallelism Same, I'm very interested in using threads in the browser but sadly thus far threading in wasm on the browser requires the server providing an extremely restrictive response header making threads impractical for most applications.
dsign 3y ago
> I haven't used it I was just curious because the JVM is a mature (and parallel) garbage collector. Slightly pedantic, but the JVM is a bit more than its arbage collectors[^1]. But it is true that the JVM has been the experimentation bed of garbage collection, not because academics have been specially daring with the JVM, but because JVM programs have been used extensively, and often so in ways that strain any single GC technique. [^1]: https://www.baeldung.com/jvm-garbage-collectors https://www.baeldung.com/jvm-garbage-collectors. The Azul JVM also has its own, different one. And those are the ones I know of; I'm pretty sure I'm leaving quite a few out.

pjmlp 3y ago

Following CLR footsteps, 22 years later. > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. From https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d...

quickthrower2 3y ago
Where is my Haskell.NET? Dammit!
- delta_p_delta_x 3y ago
  F#: https://learn.microsoft.com/en-sg/dotnet/fsharp/what-is-fsharp https://learn.microsoft.com/en-sg/dotnet/fsharp/what-is-fsha... EDIT: Yes, F# is an ML-style language. I was answering the spirit of the question, which was 'statically-typed functional-first programming language running on the .NET CLR'.
  - masklinn 3y ago
    F# is ocaml.net not haskell.net
debugnik 3y ago
If only the CLR had followed CLR footsteps as well, but they didn't even try after the DLR. Most non-Roslyn languages can barely interact with modern C# or the newer build configurations; even F# is playing catch-up and they're part of the official toolchain.
- pjmlp 3y ago
  That is the sin of guest languages, that is why C rules on UNIX, JavaScript on Web, Java on the JVM, C# on the CLR, .... Every guest language means additional IDE plugins with platform knowledge, since most communities want idiomatic libraries, an ecosystem on top of the ecosystem, as the actual platform is only implemented in a main "systems" language, mastering it is required anyway for all the leaky abstractions on the platform, additional build toolchains,... In the end, each polyglot platform achieves a global maximum of main language, and possibly a winner among all guest languages, even if it takes a couple of years with projects fading away until this happens. It sucks, however so it is the outcome of human nature attention span, and not being able to keep momentum for all languages across the whole lifetime of a given platform.
  - HappMacDonald 3y ago
    It feels to me a little bit like how geographic regions wind up working out dominant spoken/written languages. The guest languages are like relying on (human or machine) speech/writing translation services to communicate with folks who only know the local lingua franca. That added friction hobbles the minority languages. Perhaps AI will aid in greatly reducing these issues over time (and I say this because large language translation models and text to speech + speech to text are finally reaching professional human quality while running on local hardware today). But I can't think of any other good method to hold back the floodgates of people being forced to choose between their mother tongue (with its corpus of invaluable baked in stories and perspectives) and being understood by others.
  - no_wizard 3y ago
    I think Kotlin is slowly eclipsing Java on the JVM. Its not majority yet but most new projects or major refactors I've seen are either 100% Kotlin or majority Kotlin. I would not be surprised if Kotlin takes a majority share eventually
titzer 3y ago
I don't really know where to place this comment. Multi-language systems existed before, therefore Wasm should not, because it's already been done? It's interesting that none of the languages that you list made .NET a primary target and have all either bit-rotted unofficial ports or sunsetted their mainline support. It's hard to say whether languages that now target Wasm will suffer the same fate, since that depends on level of maintenance that each project allocates to particular targets. Still, I don't really get your point.
- pjmlp 3y ago
  The usual amazement as if WASM was the first at anything...
  - tambourine_man 3y ago
    Being first rarely matters. Good execution at the right time is the crucial part.
    - mtsr 3y ago
      And maybe not being the start of another MS embrace-extend-extinguish ploy.
  - refulgentis 3y ago
    People know VMs existed before WASM
saila 3y ago
I was just looking at the status of IronPython, and it's on Python 3.4, which has been end-of-life for nearly five years. I'm not sure that indicates practical usability for most developers. Only C#, VB, and maybe F# actually seem like a safe choice on .NET. (PowerShell too, but that's a different use case.) So, just because something has been, or can be, done "in theory" doesn't mean all that much. Unless you were intending this as a criticism of .NET? I could see WASM actually pulling this off.
- ejiblabahaba 3y ago
  IronPython is indeed quite a pain to work with, and for a lot of reasons beyond the age. For instance, you don't get numpy or any dependencies that themselves depend on quirks of CPython. The alternative is PythonNET, which executes python in CPython context, but provides nearly the same interoperability* with CLR assemblies. There's many devils in the details of that asterisk, and I'm frankly not knowledgeable enough to explain them; but in my experience, things work well enough that I'm satisfied with the integration provided.

kaba0 3y ago

GraalVM can run WASM executables: https://www.graalvm.org/latest/reference-manual/wasm/ https://www.graalvm.org/latest/reference-manual/wasm/

chriswarbo 3y ago

> Now I'm excited for WASM Threads for true parallelism Pedantic: threads are concurrent, not necessarily parallel. It's weird to see them called "true parallelism". I assume you mean in comparison to coroutines, but those are sequential (their execution order may be arbitrary, but we can rely on them not being concurrent). If wasm adopts threads that would be another unfortunate WorseIsBetter situation, given that threads are probably the worst model of concurrency we've ever devised (other than concurrent COMEFROM)!

titzer 3y ago
> If wasm adopts threads that would be another unfortunate WorseIsBetter situation, given that threads are probably the worst model of concurrency we've ever devised (other than concurrent COMEFROM)! Like it or not, threads are here to stay. Threads with shared mutable memory are the abstraction that multi-processor systems give software. They are not a software invention (anymore, as they might have been considered in the uniprocessor era). A key goal of Wasm is to be a portable (and safe!) abstraction over hardware. Thus exposing extremely pervasive hardware abstractions like threads is well within its mission. Doing so safely has meant careful design and specification that captures what hardware gives for memory models without forcing a new programming model or undue burden on languages, toolchains, or runtimes. Given that there are literally billions of lines of software that use threads, hardware actually implements threads, and the entire stack is driven to optimize threads, it would indeed be a bold move to impose a different abstraction at the Wasm level. An abstraction that would incidentally be immediately used to emulate threads. That's a real layering screwup--abstraction inversion. Also, I think your pedantry is unwarranted and a distraction. Many people accept the claim that threads are "true parallelism" and would consider cooperative (or even green) threading systems to be "not what we meant when we said threads". It's just a red herring to go off and discuss technicalities when the context is clearly Wasm exposing hardware threads.
- Kinrany 3y ago
  > An abstraction that would incidentally be immediately used to emulate threads. That would be a win if performance was the same!

kodablah 3y ago

> I was curious if there was a WASM to JVM and it seems there is one on GitHub [...] https://github.com/cretz/asmble https://github.com/cretz/asmble While it works well, this was mostly a fun project for me and I no longer really maintain it. I hope that the ideas and explanations of how I mapped WASM IR to JVM bytecodes helps whoever does build this in a more official capacity. I don't have any plans to support WASM GC currently.

apatheticonion 3y ago

> Now I'm excited for WASM Threads for true parallelism Same, I'm very interested in using threads in the browser but sadly thus far threading in wasm on the browser requires the server providing an extremely restrictive response header making threads impractical for most applications.

dsign 3y ago

> I haven't used it I was just curious because the JVM is a mature (and parallel) garbage collector. Slightly pedantic, but the JVM is a bit more than its arbage collectors[^1]. But it is true that the JVM has been the experimentation bed of garbage collection, not because academics have been specially daring with the JVM, but because JVM programs have been used extensively, and often so in ways that strain any single GC technique. [^1]: https://www.baeldung.com/jvm-garbage-collectors https://www.baeldung.com/jvm-garbage-collectors. The Azul JVM also has its own, different one. And those are the ones I know of; I'm pretty sure I'm leaving quite a few out.