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.
> (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.
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++.
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.
It's true that you need to ship malloc/free, but that can be really tiny too; https://github.com/fitzgen/wee_alloc is less than a kilobyte.
I don't know Rust that well, but what about unwinding and multithreading for example - don't you need to give those Rust features up if you don't want to ship any runtime code?
> It's true that you need to ship malloc/free, but that can be really tiny too
True, yeah. It's a tradeoff, though, tiny mallocs will be much slower than an optimized malloc (like dlmalloc) on real-world benchmarks.
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.
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.
I'm not sure what you mean, could you re-phrase maybe? The article is talking about compiling to WebAssembly already.
> Now if you compiled C# to webasm you potentially wouldn't need the .NET runtime
Why not? How does C# work without the runtime? As the docs for .NET Native say:
> You can continue to take advantage of the resources provided by the .NET Framework, including its class library, automatic memory management and garbage collection, and exception handling.
So you still have that runtime code in your binary, even if it's not JITted.
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.
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?
NGEN, .NET Native, CoreRT, Mono, Xamarin, IL2CPP, HPC#.
A minimal runtime is always needed, for some of the language semantics, FFI and memory management.
Still, it might be small enough.
Check the new version of Unity for browser deployment.
796 KB for a Flash like game, with the productivity of all Unity's tooling, is already more than good.
I still think that's an order of magnitude too high for a lot of use cases, but much easier to swallow for sure.