51–60 of 79 posts
Earlier quoted context omitted.
Java and .NET also have linkers, which can help bring down that size, even if not as much as Rust.
I don’t doubt they’ll get some reduction, but it will always be more than zero.
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.
Earlier quoted context omitted.
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 > (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'…
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…
Earlier quoted context omitted.
> 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.
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)
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.
Earlier quoted context omitted.
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)
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?
NGEN, .NET Native, CoreRT, Mono, Xamarin, IL2CPP, HPC#.
A minimal runtime is always needed, for some of the language semantics, FFI and memory management.
Earlier quoted context omitted.
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 > (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'…
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…
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.
> Faster-than-JS DOM performance ... > The wasm-bindgen code generation has been designed with the future host bindings proposal in mind from day 1. As soon as that’s a feature available in WebAssembly, we’ll be able to directly invoke imported functions without any of wasm-bindgen‘s JS shims. Sweet. Once again, Rust team knocking it out of the park.
"Faster-than-JS DOM performance" That will be when the clock starts ticking on Javascript. Who'da thunk one language might eventually eat both a significant chunk of C and a significant chunk of Javascript someday? I'm not saying Rust will completely eat Javascript; there is no chance that all web developers would or even necessarily could switch to Rust. But the framework war will take a very interesting turn if Rus…
That said, one really nice thing that I fear we'd lose is the interoperability of the ecosystem. There are a lot of good libraries available for Javascript that help doing webdev, and I wonder what effect fragmentation of languages could have on that. Will we trade having nicer languages for availability of useful libraries in your language of choice?
Earlier quoted context omitted.
"Faster-than-JS DOM performance" That will be when the clock starts ticking on Javascript. Who'da thunk one language might eventually eat both a significant chunk of C and a significant chunk of Javascript someday? I'm not saying Rust will completely eat Javascript; there is no chance that all web developers would or even necessarily could switch to Rust. But the framework war will take a very interesting turn if Rus…
> there is no chance that all web developers would or even necessarily could switch to Rust. But the framework war will take a very interesting turn if Rust gets faster access to the DOM than JS can provide, and is also a faster language than JS, Maybe a good way of kicking this off is if someone writes a DSL/hosted language that compiles/transpiles/whatever down into Rust. Have this language be nice and easy to writ…
Earlier quoted context omitted.
Do you see any reason why it won't eventually do so?
It's still too early. There's tons of good reasons to write C code today for many projects. Furthermore, there's so much C code out there that even if nobody wrote a single new line of C today, it'd be decades before it would go away. It's really about growing the pie rather than replacement anyway, in my opinion.
But then we can get sweet sweet COBOL level salaries in 40 years.
Earlier quoted context omitted.
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.
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 > (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'…
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.
Earlier quoted context omitted.
IIRC wasm has no GC capabilities, so Python is an unlikely source language.
In cases like that, you also compile the Python GC to wasm and use it. It ships with your app, adding bloat to your binary though. It does work!