Mono and Roslyn | Hacker News Reader

Mono and Roslyn

tirania.org

154 pointsot55 comments

Recently we have started using Mono for a huge project. We have a pure unix-based stack and everyone cringed at the idea of running a .net application on Unix but decided to give it a try.

HUGE mistake. After a couple months of development we have (today) abandoned the project and decided to take a different direction.

Mono isn't just reliable for production, as simple as that. It will inevitably have unstable and unpredictable behaviours, period. That said, it might still be good alternative for desktop local apps. Just make sure you save your work enough times during your workflow ;)

can you elaborate more on the reliability please?

Well, by "unpredictable" i mean truly unpredictable. You can randomly get seg-faults with no stack trace nor log, 100% CPU sorted only by dirty tricks that totally out of question in production-like environments, etc..

Most of the problems weren't caused by mono alone nor by the app alone. The really buggy behaviors came out with the interaction of the two.

was hoping to hear something more concrete and what you had to do to resolve it (also what finally broke the camel's back to decide to walk away). I realize it could involve a bit of verbage but given the interest in .net openness these days, some real world scrutiny would be beneficial to us interested observers.

What type of app were you running? Website or regular app? Also what version of Mono were you using? I have been running my server app for a few months now on 3.x and had some issues. For example, the default threadpool size is too small, the default implementation of FastCGI on Mono is super slow (there are alternatives out), and the GC behaves a bit differently (nursery size and collection schedule is different). I did have to learn more about the gritty details than when using .NET on Windows but you can fine tune most things. Things are running pretty smooth now though I am still trying to figure out how to debug from a GDB core dump.

Did you mix native and managed code?

Any chance of a blog post about the issues is detail? Would be interested in hearing more.

This was my experience as well. Serving c# web apps on linux just sucks.

I was using NancyFX, not ServiceStack. I wish I would have tried ServiceStack as well since I think they are probably better.

What issues were you having?

Mostly just a very difficult time figuring out the "right" way to host it on Linux. I could never get it to perform worth a damn after trying a bunch of different hosting methods.

I think ServiceStack would probably have solved my issues though.

I'm curious if you found some reference sites that had been successful running C# web apps on Mono, and if so what are they?

I know there are subtle differences in the .net memory model compared to mono. I've fallen victim to this sort of thing before and depending on what you are doing and how aware/disciplined a team is, this could very much be a pain point.

Sorry to hear that. I was running a mono-based server app for myself for some time. Never ran into any issues but my own. Ran Mono 2.10 on Ubuntu Server.

It works well enough for the servicestack people.

Sadly, we had very similar experiences.

Building a huge project on any unknown stack seems ... iffy.

Apropos this rant that I recently (re-)read: http://lua-users.org/lists/lua-l/2011-10/msg00825.html

Some other guy read about LuaJIT somewhere, so they give it a try, but obviously don't get a speedup and (of course) blame LuaJIT. They write angry letters to me, I try to politely explain to them that their design leaves something to be desired, they blame the messenger.

Then they go and write a post-mortem in a game-centric blog about how bad Lua is, that nobody should ever use scripting for anything and that their next stellar project will use C# with lots of enterprise-ready frameworks. And that they're hiring, because they got nobody with a friggin clue about C#, but management dined with someone from Redmond and they know best, of course.

Well, we are very well aware of what you mean. With us the situation was slightly different :) We hired - because our management cares - people who actually knew what they were doing, we got in touch with the person who phisically maintain the app that was running on mono and he re-assured that his software + mono were running smoothly. We have been hacking on it for months, literally. Contributed to the original project in any possible way. But THEN mono started to give strage behaviours. Unless hacking really bad on it, we understood that there was no way to deploy it in production as it could fuck up in any moment and we could do literally nothing unless deleting a file here and there and reboot.

So yeah, i'm 100% sure that things could have been done differently - better - yet this was the outcome no matter how many resources we putted on it. We never complained with the creator of the application (yet, we discussed about it with him) and for the very same reason i don't want to name the product as i'm still convinced it is indeed a good piece of software. I'm just saying that with our project, 4+ very skilled people for about 2 months ended up with nothing. Take it or leave it :)

Interesting story... but just out of curiosity, if there was already the investment made in the codebase for your application, as well as the team in place to continue with the project and maintain it afterwards, was there a consideration to switch to .NET / Windows Server?

If so, I'm curious to hear the reasoning behind abandoning the project altogether and re-writing from scratch (and likely re-interviewing and hiring a different team with different skillsets) as opposed to simply moving the production environment onto Windows...

I think a .net team could move to java relatively painlessly.

Did you ever contact the Mono team about the issues you encountered? I've found them to be very responsive about fixing serious bugs like that. You said you just abandoned the project today -- you should still follow up with the Mono devs to let them know about your problem, since it might be a small fix on their side and it'd salvage the effort your team has already put into the project.

Nope, we didn't go that far. Never got in touch with the mono team but indeed it's worth to try and i'll speak about this with the team tomorrow morning. :)

> but management dined with someone from Redmond and they know best, of course

This is usually how migrations to .NET start. Sadly.

I know there are several desktop apps built using Mono for Linux but I suppose people have their opinions with respect to Mono.

My biggest grip with Mono is the lack of automation tools (SCM in this case) and that alone is a show stopper for me. Maven and Eclipse/IntelliJ spoiled me too much that I'd rather not touch Make/Ant/CMake/MSBuild. MSBuild is Microsoft only (despite there may have been some support in Mono, as you have read the article, it's still Microsoft exclusive tool).

I'd love to use Mono to develop cross-platform desktop application. I really really really do. In fact, I decided to give it a try one time despite its shortcoming that I mentioned above. In the end, I felt that there's simply too much work for me to build any side project using Mono.

This may not be the case for serious commercial desktop app because they can invest more resources to deal with the automation tools. But for side project? Mono would definitely not on top of my list.

Have you taken a look at FAKE? http://fsharp.github.io/FAKE/

No, I have not.

It's great to see a build tool like this but my apology, the syntax is horrifying! :( (I suppose that's a personal taste).

I'm really2 spoiled by Maven because of all the things it does for me. FAKE is just like Ant/NAnt/MSBuild so it's not what I'm hoping for.

I've worked with Ant before and the build script generally becomes bloated really quick with no standard.

I'm sorry to hear that. I have been successfully running a web app on ubuntu/mono for four years now and I'm really happy about the stability and performance. It doesn't use any of the asp.net stack though.

I've been running telecom applications on Mono since 2008, doing up to a billion transactions a week across dozens of servers. After sorting out some minor deployment issues (mainly reading docs or making sure we understood which switches do what)... it just works. We've not had any unstable or unpredictable behavior. Once we've tested and gotten it working, it has stayed working.

Only thing we've had problems with I think was the LLVM backend; IIRC some of our F# code didn't work on it. But that was before Mono 3.0 and I am not sure if we checked it since.

One set of applications is typical business message processing. Read XML files, deal with SQL Server, Postgres, RabbitMQ. Another one was using the Mono runtime embedded in FreeSWITCH to do stuff to an active SIP call. FreeSWITCH's Mono integration isn't totally unused and I've yet to hear of any stability related bugs.

Would it make more sense not to abandon all that work but instead just run the project on Windows??

Saying that mono failed for your project and that you're not going to touch it again is like saying that opensource failed for your project and you're not touching it again.

Mono is a project which has a lot of different pieces of technology underneath. Please tell us the part that didn't work for you, because you cannot attribute low quality to the whole project just by testing a small part. (i.e.: was your project a web app or a desktop app? how did you host it? did your team have any Unix expertise or were just a bunch of Windows devs expecting to become Linuxers overnight?)

And most importantly, what version of Mono did you use? (Most people that complain end up saying that they just used the mono that their 4 year old distro supplied, which is a version even older than 4 years.)

That is not the case. Team with a dedicated Unix devops engineer and a windows dev consultant, all other are skilled unix devs. We have been debugging like beasts and we are probably and realistically one of the best technical teams in the country. We ran everything on Mono 3.0, which we was chosen for specific reasons and weare very aware that is a 1.5yrs old distro. The last specific problem would maybe be sorted upgrading to last release (we don't know) but we already know that new issues would rise as the pattern keeps being the same.

"we are probably and realistically one of the best technical teams in the country"

yet were unable to debug 2 months worth of new code on a mature platform, that lesser people have no troubles with.

You still haven't said the type of the app (web, desktop?), and in case of web, what technology you chose to host it (this is actually the root of many issues that people wanting to host Mono apps face, and it's kind of unrelated to Mono stack).

Completely agree. I also recently did a medium-sized project with Mono (website) because I thought that it will be cheaper since service such as digital-ocean is very cheap.

Turns out it would be cheaper to just host on Windows Azure because the work of fixing/tweaking things just so it will run properly took way more time (money) than was planned.

I have a relatively large project in production that is using a ton of legacy c# code using mono for months ;/ with little issues. Could you maybe explain more about what you saw?

I hope Unity3d improves their C# environment soon (maybe Roslyn will make it easier for them?). The Monodevelop that comes with Unity 4.3 (latest) is pretty buggy.

MonoDevelop shouldn't be affected by this at all in the short term (although eventually MonoDevelop may get new features from this). The actual Mono runtime that comes with Unity isn't getting upgraded because of licensing issues, which as far as I can tell, is because you can't ship LGPL code on certain systems (I think the App Store license is incompatible with the LGPL, for starters).

Is there any option whatsoever for Unity to use future versions of Mono, or does the GPL corruption in more recent versions mean that they're legally stuck with an outdated version?

Unity has a license from Novell for an older version of the software, which is how they can use it in places they can't use the LGPL. Xamarin sells Mono under a commercial license, but Unity apparently doesn't want to pay what Xamarin is asking for a license to the updated code.

Which is sad because the massive unity code base is stuck in the C# dark ages.

On the other hand, mono is 'open source' so it's kind of rubbish for Xamarin to be asking license fees when they have their own (pretty rubbish) competing game stack with monogame that they have a vested interest in (not commercially, but Xamarin developers work on it).

I find this sort of 'kind of open source but actually you have to pay us ahahahahaa~' thing pretty distasteful.

What is distasteful about it? Unity is not open source. If Unity were open source, it could use Mono under LGPL, no problem.

It's the 'I want a piece of your pie' thing, that I also find troubling with patents.

Person A: Invents something, fails to capitalize on it.

Person B: does marketing work, sells all the Monies!

Person A: -__- Oh that was clever. Actually, I want some of your money please.

Person B: Fuck off. <--- The correct response.

If you make something and want to sell it, sell it. If you make something and give it away for free, don't come crying when someone else sells it.

The 'dual license GPL' approach to software which is 'kind of free unless you sell it, in which case we'll negotiate some nice on going licensing fees' seems disingenuous to the spirit of open source (and specifically the GPL) to me.

You clearly don't understand open source. Go do some reading and later come back here.

Some tips: free doesn't mean "gratis", it comes from "freedom". Therefore it is normal that the GPL uses a strategy to avoid that derived works become proprietary ('proprietary' means: essentially "non-free" for the end-user, and "free" for the developer).

From your comment it seems that you confuse the fact that opensource is not something that benefits the developer; it is something that benefits the end user! Don't forget that.

Does LGPL require just the release of source code for games infected with it, or do developers have to release their assets also (like art, sound, level designs, anything needed for the code to be meaningful)?

If the assets aren't covered, I think Unity could go LGPL in some way.

That's not true. The LGPL explicitly allows closed-source programs to incorporate it (that's why it's the LGPL and not the GPL). The problem is that the LGPL is incompatible with certain use cases (embedded systems, I think the App Store, possibly the various consoles) so Unity can't distribute LGPL code to those platforms.

Mono's licensing decision actually makes sense now; hampering the free version of Mono with the contagious GPL license effectively means that you're required to pay if you want to use their software in a commercial fashion.

Very disappointing that Unity haven't upgraded yet, hopefully they'll do so soon.

The Mono runtime is LGPL (not GPL), and most (if not all) of the class libraries are MIT/X11-licensed.

> I find this sort of 'kind of open source but actually you have to pay us ahahahahaa~' thing pretty distasteful.

I find earning money on the work of others for free pretty distasteful.

Unity is free to use Mono commercially under the existing open source license, so long as they contribute their changes to the Mono runtime. They can even take advantage of this without making any of their own code open source, because Mono is licensed under the LGPL, not the GPL itself. Xamarin has made it very friendly to use Mono in commercial products without getting paid for it. I don't see what's distasteful in asking people to pay if they want license terms that go above and beyond what the LGPL offers. The commercial party gets the additional licensing features they want, and the money funds further development effort which goes to other users of Mono, both paid and libris/gratis users under the LGPL. Everybody wins.

Unity has an option. They can pay Xamarin. They don't want to. The end.

Nowadays if I needed scripting lang I would probably go with Dartlang: better license, not a clone, probably better perf, simple concurrent prog model and still syntax is familiar.

Isn't Roslyn under Apache? Or am I misunderstanding the point here?

Unity uses the Mono runtime. Roslyn is a compiler. Mono has its own compiler, actually, which is available under either the GPL or the MIT/X11 license. If having a non-LGPL compiler was sufficient for Unity, the MIT/X11 license for the Mono compiler would have already sufficed.

Keeps getting better. Let's hope there will be a single unified cross-platform .NET-Mono-Framework in future with native capabilities.

"There are also a couple of patches to deal with paths (Windows vs Unix paths)"

Is it still a problem?! Seriously?

For those of you wondering what Mono is:

  Cross platform, open source .NET development framework
  [Linux, Windows, Mac]-compatible .NET

http://www.mono-project.com

Reply on news.ycombinator.com