I plan on writing a long blog post once I get it all nailed.
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.
It sounds like you might only be doing web dev, so I appreciate that you might not have experience with this, but:
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?
Like I said, I'm about a week away from forming a solid opinion, but my guess is that I'd use 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.
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.
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.
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.