> Mono was painful, at least for me
I'm interested to hear more about mono, what was painful exactly? How is the performance compared to the MS implementation?
I'm interested to hear more about mono, what was painful exactly? How is the performance compared to the MS implementation?
It will probably go something like this: the linux environment is like running an operating system at the same time while you're coding it -- little pieces of code and scripts here and there. That makes linking, compiling, and installing the primary chores. Although there is an awesome package manager, it doesn't have the coverage you'll probably need. So lots of different pieces to plug in, lots of advice on the net, some of it bad or incomplete, and instead of just googling you end up doing quite a bit of thinking as you assemble your development environment and OS. Nothing at all like the VS2010 pnp stuff.
But I'm specifically referring to F#, which is a PITA on mono right now. I understand it's going to become part of the standard distro. Can't wait for that to happen. The default Monodevelop c# environment looks easier, but even then I'm having to do things like figure out where the gac is, find sql drivers and install them, bludgeon my way through mono dll linkage problems (Hey mono -- it's in the gac, it's in the directory, and you can compile it. Why the frack can't you find it when you run the program? I have to statically link my mysql driver, making my 2K executable into 1.5MB. That's hosed.)
Example #2: I have some generic type magic that works fine in Windows. Basically I throw an object at a function and it generates an SQL INSERT for me. Works and tested and being used in Win. Over in mono, however, for the type name all I'm getting is "System.Object" which, of course, is the correct base type, but not the real type name the caller is using. Can Mono handle this type-fu? Or am I stepping into some area the Mono guys just haven't developed yet? Don't know. Could be a while trying to track that down. Just like all these other snags.
It just seems like every little thing is more painful than it should be. Like debugging. Still haven't figured out how to get the interactive debugger to work on F#. I'm sure after an hour or two I'll figure it out -- or not. And there's 20 things like that. Because I'm new to the entire thing, each little step hurts.
I think it's doable, I think it's worthwhile, but if I were taking a team through this I would definitely want somebody onboard who has already been there, done that (and could mentor). Quite frankly doing it on my own gets a bit discouraging at times.
I've been looking at languages and VMs for doing GUI desktop app work. Specifically, cross-platform apps using native GUIs on each platform. Java (I normally use Clojure where I can) has decent cross-platform toolkits, but not so great native bindings. .NET obviously has good Windows GUI stuff, Mono's GTK# and Qyoto seem to work well for Gnome and KDE, and MonoMac seems to be going places. The main alternative seems to be to drop to low-level languages. (C, C++, Obj-C). Do you think it's worth it for me to go ahead with .NET and Mono considering the difficulties you've had with Mono?
I'm doing very simple web stuff (fcgi-type, if I can get the fcgi bindings to work) Also a bit of command-line/batch work.
As far as I can tell, .NET is the best match for what you want. If i were you, I might want to do a bit of poking around to see how the low-level stuff is configured first.
First plan of action is to build a small, (more or less) throwaway app that uses all the major bits we're interested in to get a feel for the platform before betting the farm on it.
I don't want ASP.NET. All I want is a resident .NET program that gets called when an URL is visited, getting all the parms passed like CGI. I can handle the rest.
I really don't want or need the ASP.NET stack.
Is there some way to do this? So far all I have is a stand-alone program that gets loaded each time using Apache and CGI. Can't seem to figure out how to make it resident and re-entryable without using the HttpHandler objects off the ASP.NET stack, which I don't want to do. Lord knows it was tough enough getting an environment working. Going through the motions of overriding a part of the ASP.NET pipeline in a foreign environment is probably just a bridge too far for me for this project.
Any help would be very much appreciated.
After that happened I saw a blog post by someone at microsoft about their testing. They have 1.6 testers for each dev working on asp.net and they've got a warehouse of servers running millions of different tests for months before shipping.
Then I read about who was working on mono's asp.net implementation. Just two guys in a basement. No testers of course.
Because I can deviate from the defaults so much if I wish, I was able to switch the Mono Garbage Collector from Bohem to sgen (mono --gc=sgen) and get roughly a 30% increase in reqs/sec.
There is a team dedicated to ASP.NET on Mono and I've really found them great to deal with. When I was seeing perf and memory usage issues, over a period of a couple of weeks they helped narrow it down and made some very major gains there. Those are in git master right now and will be shipping with the next mono release.
Devs often migrate from one project to another and it really is not two guys in a basement. They do call on resources from right across the project. I saw firsthand when talking to them about an issue, they discussed it with their asp.net guys, guys working on the VM, a guy working on the GC and a guy working on the new profiler and made adjustments to it to help track down the issue.
It was all done in the open, they committed their patches, it fixed my issue, and this is why I love open source.