(It's a question, not suggestion... I must admit I've never had the balls to use ML of Lisp like languages in production so far...)
The perception around Microsoft is that things can stay cheap (or even free), but at a certain point you're going to be expected to shell out the big bucks.
From our own experience, we find that Microsoft software sort-of works with other Microsoft software. However, when you want something that isn't MS to work, you're immediately into serious financial outlay.
For a start-up, this simply isn't feasible. Even a well-funded start-up has better things to spend their money on than sending it straight to Microsoft's bank account.
Overall, Mono has been incredibly smooth. I prefer to compile from source as RedHat doesn't come with packages for mono. That takes time, but isn't a big deal. F# support seems lacking when it comes to some of the tooling (compiling, interactive).
mono-service, the service daemon to act like a Windows Service host (allowing same code as on Windows, and ~5 lines to a minimal daemon) sometimes has acted weird, but it's been due to how it handles it's runfiles and lockfiles, and once you know that it's easy enough to make sure they're ok. (As in, if one user ran it, the perms are wrong so another user can't even check it, and the error messages aren't there/clear.)
F# performance is on par for .NET. If a certain high-level feature is not generating great code, there's always the option to drop down or approach another way. F#'s much more flexible than C# when it comes to performance.
F#'s why I stay on the MS stack. .NET is pretty compelling with it's base library and great tool/developer support. But after seeing powerful languages, I just get so annoyed with the verbosity of things like C#.
There are a couple of things left that annoy me, but mostly it's gone.
Even local vars can't be type inferred if they're functions, because of C#'s confusing decision to use the same syntax for lambdas and quoted code.
The ASP.NET MVC team resorted to using reflection on anonymous types, because there was no lightweight way to pass in a set of options at runtime. With a more expressive syntax, that'd be needless.
C# has statements that aren't expressions, which really bulks up code and adds flow for no reason. In F#, even "if" and "try" blocks are expressions which again keeps slimming things down, and more importantly, keeps the code simpler.
In one direct "line-by-line" translation (C#->F#), F# reduced the number type annotations I needed by 95% (1/20th).
No pattern matching (and thus no active patterns!), little type inference, no syntax for tuples, no lightweight function syntax, no code nesting, no workflows, (and a weird hardcoded one just for async), no top-level functions, no custom operators, and C# is flat-out downright clunky when compared to F#.
It may be one of those "you don't know what you'll miss until it's gone" kind of deals. I've used C# now and then, even last month on an entire project, and it just feels tiring.
1: http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-n...
Don't mistake me for a Windows fan, just pointing out that Windows's gotten a lot better than it used to be.
I'd say the compiler speed is still the biggest problem, and they're working on it.
You can certainly find examples of unreadable Haskell, specifically in the vicinity of ivory towers — there must be something in the air up there which makes academics fond of operator line noise. However, compare the following Scala [1]:
implicit def KleisliCategory[M[_]: Monad]: Category[({type λ[α, β]=Kleisli[M, α, β]})#λ] = new Category[({type λ[α, β]=Kleisli[M, α, β]})#λ] {
def id[A] = ☆(_ η)
def compose[X, Y, Z](f: Kleisli[M, Y, Z], g: Kleisli[M, X, Y]) = f <=< g
}
newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b }
instance Monad m => Category (Kleisli m) where
id = Kleisli return
(Kleisli f) . (Kleisli g) = Kleisli (\b -> g b >>= f)
[2]: https://github.com/ghc/packages-base/blob/master/Control/Arr...
(With unconventional syntax admittedly)
Linked list as primary data structure? Check Functional? Check Macros? Check (Implemented as normal functions, since with lazyness you don't actually need macros for control-structure type constructs)
Anything you can write as a macro in lisp you can write as a normal function in haskell, without special gymnastics.