Comment by acak | Hacker News Reader

Comment by acak | Hacker News Reader

I am a developer who has leaned towards .NET over the last few projects and one of the things that used to nag me is that the platform is a closed one (and the licensing fees can be a decent part of the cost). I was fairly certain I would migrate off it if the project ever took off seriously.

And after seeing the C# love on HN on the poll for favorite programming languages last week, I realized there must be many enamored .NET programmers who would use and evangelize it more but only don't due to it being a closed platform.

Also, a lot of us have great ideas to make the platform we're using better - and with Microsoft announcing they'd make Json.NET, a third party JSON library, the default JSON serializer over their home-grown DataContractJsonSerializer in the next version of ASP.NET MVC, I wondered if Microsoft was considering the unthinkable: start accepting community developed features into their platform, and perhaps open source it to make the scope for community contributions even larger.

There's a long way to go to fully realize this vision (I'd like for .NET itelf to be open source ;-] ), but this is just incredible news.

For those who want to understand which parts of the ASP.NET stack are open source, check out this diagram on Hanselman's blog that was very useful to me.

http://www.hanselman.com/blog/VisualStudio11BetaInContext.as...

> Microsoft announcing they'd make JSON.NET, a third party JSON library, the default JSON serializer over their home-grown DataContractJsonSerializer in the next version of ASP.NET MVC

Finally! For those who haven't used it, DataContractJsonSerializer has the most absurd way of serialising dictionaries into JSON. Rather than producing {"k1": "v1", "k2": "v2"} it produces [{"Key": "k1", "Value": "v1"}, {"Key":"k2", "Value": "v2"}]

> DataContractJsonSerializer has the most absurd way of serialising dictionaries into JSON.

DataContractJsonSerializer is a hack that is built on top of an XML parser.

For the people who are unfamiliar with .NET there is a comparison of Json.NET to Microsoft's two JSON serializers here:

http://json.codeplex.com/ <- Json.NET homepage

For a big old school company like Microsoft to accept patches from the community is huge. I always grudgingly accepted there must be some sort of commercial risk ("Microsoft used my code and made 10 million dollars, now I'm going to sue them") holding them back.

Does anybody have insight on this topic? I'm currently building something that would benefit greatly from user contributions of code, but I'm wary about the legal implications (the project will be a commercial site, and while I have no problem publishing their code if I choose to integrate it into my site to enhance the user experience, I have no interest in publishing the core code for the rest of the site).

I'd pay to have a fully compatible .NET stack on OSX/Linux. Most of our backend code is C#; outside of having to use Windows I've actually found it very pleasant to work with. No need for a full MSVS port, just a working VM/library and build tools (+ maybe an IntelliSense daemon to plug into editors). It'd be interesting to see MS get back to their roots this way.

I'm completely with you: I absolutely love .NET, but I really wish that I could write server-side components for and on OS X or Linux. Mono's getting less painful for server-side work, for what it's worth; if you have light needs, or can easily restart the service on a regular basis, you may find it usable. But I'd definitely avoid deploying an MVC 3 app.

> if you have light needs, or can easily restart the service on a regular basis, you may find it usable. But I'd definitely avoid deploying an MVC 3 app

Can you further elaborate on that one? Because that's exactly what I would like to do.

Mono had two issues we hit in production for server processes:

1. The GC was poor. There's actually a couple of pieces to this one: it's non-compacting, so your app gradually slows down; and (because it's Boehm) it has to guess at what's a pointer, and sadly just doesn't do a good job, so you gradually leak RAM through no fault of your own. The new GC, which I think is called SGen, is a precise collector, so I assume that it fixes the memory leaks, but it's still non-compacting, meaning you're probably going to want to restart the process every once and awhile to prevent serious heap fragmentation.

2. Mono gradually became unstable the longer it ran. This grew exponentially worse as you added threads.

Both of these issues can be circumvented by having multiple processes in a load-balanced configuration and simply restarting them every once and awhile. Heck, IIS does that with App Pool recycling anyway, and it doesn't have these issues.

The FogBugz team still uses Mono to host FogBugz on Unix systems, I believe by going the reboot-every-so-often route, so I assume they've found ways of living with the above two constraints.

Remember that Mono is open source and we'd LOVE to get patches to improve it.

Bug reports also help!

In the meantime, we're working hard to constantly be improving Mono, but the best way to improve free/open source software is to get involved.

How long ago did you experience those issues? I still have some time to go until I launch whatever it is I decide to build. I hope the Mono team finds a solution for them eventually.

I think .NET is great, and most of my career has been working in C#, but targeting Windows and developing on Windows is just a bummer.

mono

Reply on news.ycombinator.com