Live data from Hacker News

Mono and WebAssembly – Updates on Static Compilation

mono-project.com

21–30 of 47 posts

Re: Mono and WebAssembly – Updates on Static Compilation

#21
post #18

I've always envied the JVM's class reloading abilities. Edit-n-continue in Visual Studio has so many "it doesn't work if you do this" cases, that's it next to useless. I would love to be able to put the C# debugger into interpreter mode and be able to change anything, anywhere while debugging and keep on trucking without having to stop debugger, make changes, restart debugger, etc..

I crave this for C#/.NET; I was hoping the article was going to mention something about faster edit cycle w.r.t. normal apps. It came pretty close:

> ... uses the new Mono IL interpreter to run managed code at runtime... to be used for quickly reloading C# code and prototyping

So maybe it will/can provide the foundation for faster edit cycles with native apps and not just WASM.

Re: Mono and WebAssembly – Updates on Static Compilation

#23
post #18

I've always envied the JVM's class reloading abilities. Edit-n-continue in Visual Studio has so many "it doesn't work if you do this" cases, that's it next to useless. I would love to be able to put the C# debugger into interpreter mode and be able to change anything, anywhere while debugging and keep on trucking without having to stop debugger, make changes, restart debugger, etc..

Even the JVM has a fair number of issues if you use class reloading to do Weird Stuff (tm), especially with advanced debugger tricks added into the mix. That's one of the reasons some of the folks I know who use Scala switched in the first place. I think any hot-reloading solution for a big, complex, introspective/reflective language is going to have some warts* and places where it stops working in some scenarios. Th…

I ended up with a pretty sweet workflow that involved hot code reloading in a Clojure web app where I rarely needed to restart the dev JVM. It involved Emacs and CIDER and designing the app’s architecture in a certain way but I felt it was really worth it. That said, if I was using a language with faster start up time then I’d have just restarted after every major change and not even worry about this, but this has some benefits that don’t exist in that scenario.

Re: Mono and WebAssembly – Updates on Static Compilation

#24
post #3

Awesome. > This currently requires MacOS High Sierra to run. Ha, feels strange to say it, but "waiting for a Windows version". Also for the latest Mono preview targeting WebAssembly [0], I wanted a Windows nightly...went and looked at the Mono site's nightly downloads...nope, Linux and macOS only. Heh. 0 - http://www.mono-project.com/docs/about-mono/releases/5.8.0/

> Ha, feels strange to say it, but "waiting for a Windows version".

I can understand the lack of a Windows version.

What I can’t understand is why this won’t on Linux.

Re: Mono and WebAssembly – Updates on Static Compilation

#25
post #6
post #4

Has anyone heard about Microsoft working on a similar project? The proof of concept last summer seemed to have raised a lot of interest among Microsoft people. I hope they take that route.

We are Microsoft employees :-)

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

Re: Mono and WebAssembly – Updates on Static Compilation

#26
post #6
post #4

Has anyone heard about Microsoft working on a similar project? The proof of concept last summer seemed to have raised a lot of interest among Microsoft people. I hope they take that route.

We are Microsoft employees :-)

Yes. Please make C#->WASM robust and production capable.

Now please. Now now now!

Re: Mono and WebAssembly – Updates on Static Compilation

#27

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.

Re: Mono and WebAssembly – Updates on Static Compilation

#29
post #3

Awesome. > This currently requires MacOS High Sierra to run. Ha, feels strange to say it, but "waiting for a Windows version". Also for the latest Mono preview targeting WebAssembly [0], I wanted a Windows nightly...went and looked at the Mono site's nightly downloads...nope, Linux and macOS only. Heh. 0 - http://www.mono-project.com/docs/about-mono/releases/5.8.0/

> Ha, feels strange to say it, but "waiting for a Windows version". I can understand the lack of a Windows version. What I can’t understand is why this won’t on Linux.

A significant portion of the main webassembly development teams at google & apple (and probably mozilla, but I'm not sure) use macs, and I think that's true for many mono developers also. The linux and windows (especially windows) toolchains are neglected.

For a while the canonical webassembly tooling and test suite were unusable on Windows due to the selection of software that didn't work there. It was a bummer (that was corrected, at least!)

Re: Mono and WebAssembly – Updates on Static Compilation

#30

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?

Yes, I think that's part of mscorlib.dll.

The GC lives in the runtime, IIRC every runtime's GC is native code and most of them have their own. If memory serves most of the official Microsoft runtimes share the same GC implementation (it's open-sourced in CoreCLR), but I'm not 100% sure on that. Mono has two GCs, Boehm and SGen, and the latter is custom.
Post reply on HN