Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mono and WebAssembly – Updates on Static Compilation

mono-project.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Mono and WebAssembly – Updates on Static Compilation

#31

Post by kevingadd »

yodon wrote: post #19
j_s wrote: post #17

Earlier quoted context omitted.

Investigate a possibility to support JSX | https://github.com/bridgedotnet/Bridge/issues/808 Bridge.NET translates C# to JavaScript, but JSX is not currently supported.

I like Bridge.NET but I’m not sure how they will survive once the current Mono WebAssembly tech hits release.

WebAssembly does not cover use cases that require a ton of C#JS interop, and it may never adequately cover it. You end up needing a very complex interop bridge similar to CJS interop. A solution like Bridge can compile to JS, making interop near-zero-cost.

Re: Mono and WebAssembly – Updates on Static Compilation

#32

Post by kevingadd »

sydd wrote: post #25
lrz wrote: post #6

Earlier quoted context omitted.

We are Microsoft employees :-)

Why are there currently 2 projects aiming to run C# code in WebAssembly? I mean this one and coreRT?

Lots of people out there use mono, and if they want to run in the browser, it wouldn't hurt for mono to have webassembly support would it? :)

Re: Mono and WebAssembly – Updates on Static Compilation

#33

Post by waf »

MarkSweep wrote: post #10
algorithmsRcool wrote: post #7

Earlier quoted context omitted.

Edit : I misread this article. Neiter of the projects i mentioned target webassembly. But CoreRT could one day. Microsoft has two similar projects: CoreRT : Which is a managed re-implementation of the CLR allowing for AoT compilation. LLILC : A LLVM Backend for .NET MSIL. (Stalled) https://github.com/dotnet/corert https://github.com/dotnet/llilc

CoreRT's WASM support is being worked on: https://github.com/dotnet/corert/tree/master/src/ILCompiler.... There are some instructions here: https://github.com/dotnet/corert/blob/master/Documentation/h...

You can also contribute and track the progress here: https://github.com/dotnet/corert/issues/4659

Re: Mono and WebAssembly – Updates on Static Compilation

#34

Post by yodon »

kevingadd wrote: post #31
yodon wrote: post #19

Earlier quoted context omitted.

I like Bridge.NET but I’m not sure how they will survive once the current Mono WebAssembly tech hits release.

WebAssembly does not cover use cases that require a ton of C# JS interop, and it may never adequately cover it. You end up needing a very complex interop bridge similar to C JS interop. A solution like Bridge can compile to JS, making interop near-zero-cost.

Thanks for fantastic answer to my concern (for those who might object that kevingadd didn’t cite his sources, given his background he pretty much -is- a primary source)

Re: Mono and WebAssembly – Updates on Static Compilation

#35

Post by yodon »

testvox wrote: post #27
Humphrey wrote: post #22

How does this handle garage collection? I believe Webassembly doesn't yet support GC so, is this manually compiling it's own GC into it?

Mono already supports embedding the runtime with the application. So they just used that feature here. Also available is the mono interpreter which does it's own garbage collection.

It’s more complex than that, as there’s tons of academic work essentially proving it’s impossible to chain two independent garbage collectors and not end up with stuck uncollectable memory (I apologize, this isn’t my field, I’ve skimmed the work but not retained the citations, and I realize how counter-intuitive that result is... nobody wants to think its true, so it keeps getting more academics thrown at it, without changing the results).

My assumption is that at the moment they are just accepting that some uncollectable memory will happen in the short term and eventually the WebAssembly working group will expose the underlying garbage collector and everything will get better. Early days kind of issue for now.

Re: Mono and WebAssembly – Updates on Static Compilation

#36

Post by justin66 »

eosrei wrote: post #16
sirjaz wrote: post #5

This awesome, I much prefer to code in C# as compared to js. It is a much cleaner language.

https://github.com/appcypher/awesome-wasm-langs is the full list of WebAssembly languages and their current status.

I wasn't sure if this list would be any good, but it says right at the top that it's "curated." Imagine my relief!

Re: Mono and WebAssembly – Updates on Static Compilation

#37

Post by gsnedders »

yodon wrote: post #35
testvox wrote: post #27

Earlier quoted context omitted.

Mono already supports embedding the runtime with the application. So they just used that feature here. Also available is the mono interpreter which does it's own garbage collection.

It’s more complex than that, as there’s tons of academic work essentially proving it’s impossible to chain two independent garbage collectors and not end up with stuck uncollectable memory (I apologize, this isn’t my field, I’ve skimmed the work but not retained the citations, and I realize how counter-intuitive that result is... nobody wants to think its true, so it keeps getting more academics thrown at it, without…

In the WASM case it's trivial to show how this is the case at the moment: WASM just has a large ArrayBuffer, which the JS GC will hold on to all of, regardless of how much the GC in WASM deallocates.

Re: Mono and WebAssembly – Updates on Static Compilation

#40

Post by skrebbel »

justin66 wrote: post #36
eosrei wrote: post #16

Earlier quoted context omitted.

https://github.com/appcypher/awesome-wasm-langs is the full list of WebAssembly languages and their current status.

I wasn't sure if this list would be any good, but it says right at the top that it's "curated." Imagine my relief!

Hahah :-)

Yeah it's a mess. GitHub is full of "Awesome XYZ" lists which are basically just dumps of links. Awesome Elixir is a good example, it's worthless and full of 2-year old unmaintained afternoon hacks.

Post reply on HN