Still no .NET support? :(

What? It supports .Net, it just doesn't have .NET FFI.

.NET works, and we will do basic maintenance on it to ensure that things in Fantom are portable. However, it is not a core focus - what receives our priority is JVM and JS support which we use in our commercial products.

So I would characterize .NET runtime as a prototype and proof of concept, but not something I would recommend for production.

If anyone in community would like to take ownership of the .NET runtime that would be awesome and I would be happy to work with you.

Thanks, Brian. I'd love to help out whereever I can, but I wouldn't know where to start. Is there something specific you want to focus on in the .net runtime?

Hi Jason,

The core .NET runtime is fairly complete - all fcode should be loaded into the CLR correctly by the emitter. The primary work in .NET is implementing all of the sys types and methods, along with other pods that use natives. A quick summary:

• sys: mostly flushed out, and I try to maintain it, but sometimes refactorings and various changes don't fully get ported from Java to C#. Since no one uses .NET on a daily basis like the JVM runtime, stuff easily falls thru the cracks - luckily pretty much every single type and slot in sys has extensive tests in testSys
• inet: was fully functional at one point, but think I commented out tests for C# at some point
• concurrent: this mostly worked when these APIs were part of sys, but they have not been refactored to use new model
• fwt: this is a HUGE project, and probably one of the last things we'd want to tackle (less core than concurrent and inet)

Luckily virtually everything that matters should have a test suite, so really it is just running thru each test until everything passes. For example, once testSys and testCompiler work that means we have a super solid core.

The other main issue with .NET that troubles me before it is production ready is that the fcode to emit process is painfully slow. Some of this is because .NET can only load an assembly at a time, so it is not as elegant and flexible as Java's class loader design. But I'm sure with things like the DLR there might be better ways to solve this problem.

If you really want to try to dip your toes into something, why don't you email directly (briansfrank on gmail).