Mono and WebAssembly – Updates on Static Compilation | Hacker News Reader

Mono and WebAssembly – Updates on Static Compilation

mono-project.com

109 pointsbenaadams46 comments

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!)

Yeah, mac-books are one of the favorite choices of unix focused devs. So quite a few people at Xamarin are using that.

Also, they are a MacOS focused shop in some ways (Xamarin for iOS).

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!

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.

You might like Typescript. A lot of the niceness of C# but much more lightweight.

Typescript as a language may be more lightweight (i.e fewer features) than C# but the development process feels extremely heavyweight and convoluted in comparison.

Typescript has no standard library. So you have to resort to using JavaScript libraries and combine those with type descriptions written by yet another group of people for some version or other of the original library.

So essentially Typescript is importing JavaScript's already onerous dependency situation putting another set of dependencies on top of it without any formal correctness guarantees or automated compatiblity checks.

The language itself is under constant threat of breaking changes introduced by new JavaScript versions.

The whole setup feels exremely fragile to me and it is anything but lightweight. But I accept that many people are successfully navigating this mess for now, people who (unlike myself) have created actual production software in Typescript.

We'll see how it works out longer term.

Fair point, however I don't see how the situation will be drastically different for C#. The browser still uses JavaScript and I suspect any C# implementation for the browser will use typescript's definition files anyway.

> So essentially Typescript is importing JavaScript's already onerous dependency situation putting another set of dependencies on top of it without any formal correctness guarantees or automated compatiblity checks.

An increasing number of JS libraries on npm maintain and provide their own Typescript definitions, so the ecosystem is getting better and in some cases there are no additional type information dependencies beyond your JS library dependencies.

> The language itself is under constant threat of breaking changes introduced by new JavaScript versions.

I've used Typescript in production software since around TS 1.0, and Typescript has been very adroit of working ahead of JS versions. The biggest change, and closest to a compatibility break, was that import/export syntax changed slightly to reflect ES module import/export syntax, and that wasn't entirely a breaking change (the old syntax still works, though is marked with a deprecation warning). On the other side there were ES2015 features I was happily using in Typescript years before ES2015 was finalized, and am happily using proposed features that are only Stage 2 or Stage 3 today in the standards process.

Ecma's TC39 is following a similar playbook to the rest of web standards and using an approach to where multiple implementations should be built before the proposal is accepted into the language. TC39 has the benefit that not only do they get browser implementations, but polyfills/prollyfills, Babel, and Typescript implementations to learn from in adopting a proposal.

Typescript very much is leading JS development as much as, if not more than, it is following.

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. The trick is just to minimize those to where they don't get on your nerves on a daily basis. C# will hopefully get there soon.

* Unless, that is the language is designed from the ground up to support code reloading. Erlang/Elixir's runtime inspection/injection/behavior alteration capability is second to none, and largely replaces the role of a true/traditional debugger. And you can do other cool stuff with it like zero-downtime in-place deployments, though that doesn't exactly come for free.

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.

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.

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.

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.

Xamarin.Android begs to differ. It provides full integration and all we use from Dalvik are gc handles and explicit GC control.

Full Disclosure: I work at MS and I am one of the original designers of 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.

They are compiling libmono (an embeddable .net runtime) to wasm. That runtime has its own GC.

Does anyone know if there is work being done to add JSX syntax to C# (either into the language directly or as part of a pre-processor)?

The CSharpLang github[1] repository would be where to look for this. I didn't find anything that mentioned adding language support for it, and IIRC, in the past they rejected the idea of inline XML or JSON support.

Going the other way of C# inside HTML, you have Razor[2] and Blazor[3], the latter of which is a prototype of Razor running in the browser via web assembly.

[1]: https://github.com/dotnet/csharplang [2]: https://docs.microsoft.com/en-us/aspnet/core/mvc/views/razor [3]: http://blog.stevensanderson.com/2017/11/05/blazor-on-mono/

Blazor is pretty amazing, but my coder fantasies mostly revolve around a React-JSX-in-C# vision - the syntax and approach just feel so natural and so right. Your point about rejecting inline XML is probably a pretty good data point that I shouldn’t expect what I’m hoping for to happen.

Well, if you would use VB.NET instead, it supports XML literals.

Why would you pick jsx instead of TSX?

JSX is the the syntax for embedding HTML in a non-HTML language. TSX is just a file extension implying that the non-HTML language is typescript, which it wouldn’t be here because C#.

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 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)

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 :-)

I meant Microsoft as in throwing the full weight of Visual studio integration and tooling!

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? :)

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

Now please. Now now now!

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...

Very cool! It seems I was more correct than I thought.

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

Blazor is an experimental web UI framework using C#/Razor and HTML, running client-side via WebAssembly.

Blazor : https://github.com/SteveSanderson/Blazor

Xamarin is Microsoft :)

Reply on news.ycombinator.com