> 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.
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 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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)
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#.
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.
> 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/