4 ms·

Rust isn't the only player here. Kotlin I think does webasm already. And I think Java and C# will also jump on the bandwagon eventually.

steveklabnik 9y ago
Rust has some significant advantages compared to languages like Kotlin, Java, and C# here. A really big one is binary sizes. To get those languages to work, you have to ship the entire runtime. For example, see https://www.infoq.com/news/2018/01/mono-cs-webassembly https://www.infoq.com/news/2018/01/mono-cs-webassembly > (the "hello world" example is 10 megabytes) The "hello world" example in Rust is ~100 bytes. Some applications and some people can pay these costs, it's true. But tiny binaries is quite appealing. It's even part of the reason that WebAssembly was created in the first place.
- pjmlp 9y ago
  Java and .NET also have linkers, which can help bring down that size, even if not as much as Rust.
  - steveklabnik 9y ago
    I don’t doubt they’ll get some reduction, but it will always be more than zero.
    - pjmlp 9y ago
      Yep, as I stated it is never going to be as small as Rust. Still, it might be small enough. Check the new version of Unity for browser deployment. https://youtu.be/EWVU6cFdmr0 https://youtu.be/EWVU6cFdmr0 796 KB for a Flash like game, with the productivity of all Unity's tooling, is already more than good.
      - steveklabnik 9y ago
        That's awesome! I still think that's an order of magnitude too high for a lot of use cases, but much easier to swallow for sure.
- maxxxxx 9y ago
  Doesn't the small size only apply if you compile to assembly? If you compile to webasm shouldn't things be different? I am assuming a C# to webasm would be very different from the current C# to IL compiler.
  - steveklabnik 9y ago
    > Doesn't the small size only apply if you compile to assembly? If you compile to webasm shouldn't things be different? I'm not sure what you mean, could you re-phrase maybe? The article is talking about compiling to WebAssembly already.
    - yougane 9y ago
      I think what he means is that C# apps would have a smaller size if AOT compiled to wasm instead of shipping the mono runtime with .NET assemblies. (sorry for my English)
      - steveklabnik 9y ago
        Your English is fine! I don’t know enough about how C# is AOTd to really answer that. I mean, some runtime code would still need to be in there, I assume?
        pjmlp 9y ago
        Yes, the approach is similar to all major AOT compilers on .NET space. NGEN, .NET Native, CoreRT, Mono, Xamarin, IL2CPP, HPC#. A minimal runtime is always needed, for some of the language semantics, FFI and memory management.
      - pjmlp 9y ago
        C# has been AOT compiled since the early days. Just that only dynamic linking was supported on the regular .NET Framework. Unity(with IL2CPP), Mono and Windows 8 store apps also support static linking. So the approach is the same as Xamarin for iOS or .NETbon the Windows store. There is an additional phase that generates the native code, using MSIL as just yet another compiler phase. As for the runtime, yes there needs to be a minimal set of services. But even C, C++, Go, ... need to have some kind of runtime if you want to use all language features.
- azakai 9y ago
  C# etc. shipping a runtime is a current limitation of wasm and those ports to wasm. But in principle once wasm has GC support they can also compile to tiny binaries. Not for everything, of course - if you use certain C#/Java/Kotlin features you'll need bundled runtime support. But if you avoid them, you don't. For comparison, Rust can't emit tiny binaries if you use malloc/free, because it needs to bundle those. This is actually an area where Rust/C/C++ are at a disadvantage once wasm has GC, as GC will be "free" while malloc/free won't be, so many programs will be smaller as C#/Java/Kotlin rather than Rust/C/C++.
  - kbenson 9y ago
    Is it really on the roadmap to support GC before a simple API level malloc/free? It seems like the sane progression path would be to have WASM support an API for malloc/free first (which would be useful any system that supports a pluggable memory allocator, as Rust is getting), them an API for requesting garbage collected bytes of memory (which I assume, with fairly little prior knowledge, malloc/free would be useful for).
    - azakai 9y ago
      I'm not aware of any plans to support a malloc/free API currently. GC plans are already underway. Thinking about it, it's actually not that obvious how to support a malloc/free API. It seems like it would need to be deterministic to fit properly on the Web. But writing a spec for that is not easy since efficient malloc/frees are fairly complex and detailed. And once specced out, it could never be improved. GC on the other hand already exists on the Web, and all the complexity is not noticeable (except for things like proper weak refs and finalizers, which is why those have not been added to the Web yet) so the spec is fairly simple and it allows constant optimization on the implementation side.
  - tuukkah 9y ago
    >GC will be "free" while malloc/free won't be malloc is several magnitudes simpler than GC though. Then there's the question when (if ever) wasm will have GC and what kind of GC will it be.
  - 9y ago
- peoplewindow 9y ago
  Kotlin specifically has a "native mode" where it doesn't use the JVM and ships its own small runtime with a ref-counting cycle detecting gc, C interop and not much else. The binaries aren't 100 bytes but I suppose with more optimisation they could be. And although Kotlin/Native isn't actually exactly the same language as Kotlin/JVM it's got very good usability and IDE support already. So I think it can be quite a strong competitor for Rust in many areas.
yougane 9y ago
C# already jumped on the bandwagon with Blazor https://github.com/aspnet/Blazor https://github.com/aspnet/Blazor

steveklabnik 9y ago

Rust has some significant advantages compared to languages like Kotlin, Java, and C# here. A really big one is binary sizes. To get those languages to work, you have to ship the entire runtime. For example, see https://www.infoq.com/news/2018/01/mono-cs-webassembly https://www.infoq.com/news/2018/01/mono-cs-webassembly > (the "hello world" example is 10 megabytes) The "hello world" example in Rust is ~100 bytes. Some applications and some people can pay these costs, it's true. But tiny binaries is quite appealing. It's even part of the reason that WebAssembly was created in the first place.

pjmlp 9y ago
Java and .NET also have linkers, which can help bring down that size, even if not as much as Rust.
- steveklabnik 9y ago
  I don’t doubt they’ll get some reduction, but it will always be more than zero.
  - pjmlp 9y ago
    Yep, as I stated it is never going to be as small as Rust. Still, it might be small enough. Check the new version of Unity for browser deployment. https://youtu.be/EWVU6cFdmr0 https://youtu.be/EWVU6cFdmr0 796 KB for a Flash like game, with the productivity of all Unity's tooling, is already more than good.
    - steveklabnik 9y ago
      That's awesome! I still think that's an order of magnitude too high for a lot of use cases, but much easier to swallow for sure.
maxxxxx 9y ago
Doesn't the small size only apply if you compile to assembly? If you compile to webasm shouldn't things be different? I am assuming a C# to webasm would be very different from the current C# to IL compiler.
- steveklabnik 9y ago
  > Doesn't the small size only apply if you compile to assembly? If you compile to webasm shouldn't things be different? I'm not sure what you mean, could you re-phrase maybe? The article is talking about compiling to WebAssembly already.
  - yougane 9y ago
    I think what he means is that C# apps would have a smaller size if AOT compiled to wasm instead of shipping the mono runtime with .NET assemblies. (sorry for my English)
    - steveklabnik 9y ago
      Your English is fine! I don’t know enough about how C# is AOTd to really answer that. I mean, some runtime code would still need to be in there, I assume?
      - pjmlp 9y ago
        Yes, the approach is similar to all major AOT compilers on .NET space. NGEN, .NET Native, CoreRT, Mono, Xamarin, IL2CPP, HPC#. A minimal runtime is always needed, for some of the language semantics, FFI and memory management.
    - pjmlp 9y ago
      C# has been AOT compiled since the early days. Just that only dynamic linking was supported on the regular .NET Framework. Unity(with IL2CPP), Mono and Windows 8 store apps also support static linking. So the approach is the same as Xamarin for iOS or .NETbon the Windows store. There is an additional phase that generates the native code, using MSIL as just yet another compiler phase. As for the runtime, yes there needs to be a minimal set of services. But even C, C++, Go, ... need to have some kind of runtime if you want to use all language features.
azakai 9y ago
C# etc. shipping a runtime is a current limitation of wasm and those ports to wasm. But in principle once wasm has GC support they can also compile to tiny binaries. Not for everything, of course - if you use certain C#/Java/Kotlin features you'll need bundled runtime support. But if you avoid them, you don't. For comparison, Rust can't emit tiny binaries if you use malloc/free, because it needs to bundle those. This is actually an area where Rust/C/C++ are at a disadvantage once wasm has GC, as GC will be "free" while malloc/free won't be, so many programs will be smaller as C#/Java/Kotlin rather than Rust/C/C++.
- kbenson 9y ago
  Is it really on the roadmap to support GC before a simple API level malloc/free? It seems like the sane progression path would be to have WASM support an API for malloc/free first (which would be useful any system that supports a pluggable memory allocator, as Rust is getting), them an API for requesting garbage collected bytes of memory (which I assume, with fairly little prior knowledge, malloc/free would be useful for).
  - azakai 9y ago
    I'm not aware of any plans to support a malloc/free API currently. GC plans are already underway. Thinking about it, it's actually not that obvious how to support a malloc/free API. It seems like it would need to be deterministic to fit properly on the Web. But writing a spec for that is not easy since efficient malloc/frees are fairly complex and detailed. And once specced out, it could never be improved. GC on the other hand already exists on the Web, and all the complexity is not noticeable (except for things like proper weak refs and finalizers, which is why those have not been added to the Web yet) so the spec is fairly simple and it allows constant optimization on the implementation side.
- tuukkah 9y ago
  >GC will be "free" while malloc/free won't be malloc is several magnitudes simpler than GC though. Then there's the question when (if ever) wasm will have GC and what kind of GC will it be.
- 9y ago
peoplewindow 9y ago
Kotlin specifically has a "native mode" where it doesn't use the JVM and ships its own small runtime with a ref-counting cycle detecting gc, C interop and not much else. The binaries aren't 100 bytes but I suppose with more optimisation they could be. And although Kotlin/Native isn't actually exactly the same language as Kotlin/JVM it's got very good usability and IDE support already. So I think it can be quite a strong competitor for Rust in many areas.

yougane 9y ago

C# already jumped on the bandwagon with Blazor https://github.com/aspnet/Blazor https://github.com/aspnet/Blazor