He estado usando Mono en Linux durante unos tres años, y últimamente he estado usando en OS X. Algunas de las cosas Linux era bastante amplia, pero las cosas OS X acaba de haber un sencillo ASP.NET MVC2 aplicaciones hasta ahora.
1) El rendimiento de Mono nunca ha sido un problema para mí. Eso no quiere decir que el rendimiento no haya sido importante, es solo que el rendimiento de Mono nunca ha sido un problema. Mucho de lo que he hecho está basado en la web, así que el uso de la memoria de E/S y la base de datos me han afectado antes que Mono.
Históricamente, la mayor deficiencia con Mono ha sido el recolector de basura (GC). Diría que Java está mejor sintonizado en este sentido. Las versiones más recientes de Mono han logrado grandes avances en esta área, pero no tengo ningún número difícil para ti en términos de comparación.
Estoy seguro de Mono es más rápido veces y Java a veces, pero yo diría que Java es más rápido en general.
2) Sin duda puede hacer el desarrollo Mono con makefiles. Ciertamente, el equipo Mono sí mismo. También puedes usar Emacs y hay un C# mode for it.
tiendo a usar MonoDevelop y xbuild (versión Mono de msbuild) a mí mismo y no tienen ninguna experiencia haciendo C# trabajo en Emacs. MonoDevelop es genial porque es exactamente igual en todas las plataformas. Además, aunque rara vez lo uso, es bueno que el formato del proyecto sea el mismo que Visual Studio y SharpDevelop.
3) MonoDevelop tiene soporte de factorización de código bastante decente. Es lo mismo en Windows, Linux y Mac. No necesita usar Windows para el desarrollo (aunque ciertamente puede) pero creo que será más feliz usando un IDE como MonoDevelop. Incluso cosas como Intellisense se vuelven difíciles de vivir una vez que estás acostumbrado a ellas. Pero la depuración integrada, la posibilidad de profundizar en el marco, la integración de bases de datos, la prueba de unidades, la integración de SCM y otras herramientas útiles, todo en un solo lugar, es el camino a seguir (al menos para mí).
4) Mono no se preocupa por el control de versiones, por supuesto. Sus archivos de origen son solo texto y puede usar cualquier cosa para administrarlos.
Dicho esto, MonoDevelop tiene una fantástica compatibilidad con Subversion integrada en el IDE. Lo he usado extensamente y es una de las razones por las que tengo problemas para mover MonoDevelop incluso en Windows. La última versión de MonoDevelop (2.6 beta) también incluye compatibilidad con Git.
No mencionaste las pruebas unitarias pero MonoDevelop también tiene soporte NUnit integrado en el IDE. Lo uso en todos los proyectos y funciona de manera excelente. La versión en MonoDevelop es 2.4.8 (si la memoria sirve) por lo que no es bastante actual, pero funciona muy bien.
En pocas palabras, Mono funciona muy bien con herramientas de código abierto en general. Siempre me ha jugado muy bien.
Autoconf es, por supuesto, utilizado por el proyecto Mono en sí, pero, como desarrollador Mono, nunca he visto la necesidad de hacerlo. Me esfuerzo por usar solo código administrado en mis proyectos. Como tal, todo lo que necesito en la plataforma de destino es Mono (o .NET). No tener que preocuparse por todo eso es uno de los principales beneficios de un entorno administrado como Mono o Java. El tiempo de ejecución en sí (el CLR) garantiza que mi aplicación tenga todo lo que necesita para funcionar correctamente.
Sé que MonoDevelop creará archivos autoconf/autorun para proyectos C/C++ (no mono) pero no he hecho mucho con él.
En cuanto a un comentario anterior, el Mono JIT obviamente está sintonizado a la plataforma de destino. Ahí es donde ocurre el ajuste de rendimiento específico de la plataforma.
Al igual que un comentario, me parece que Mono se ve mejor como un entorno de desarrollo por derecho propio que como una capa de compatibilidad para cosas de Microsoft. El equipo de Mono ha extendido .NET de muchas maneras interesantes. Todo lo que desarrolle para Mono se ejecutará en .NET, pero hay algunas características de .NET no disponibles para Mono. Por ejemplo, Mono no es compatible con Windows Presentation Foundation (WPF). Debe usar Windows Forms o GTK # para el trabajo de GUI multiplataforma. También puede usar algo como Cocoa # o MonoMac en la Mac, MonoTouch en iPhone o MonoDroid para Android. También puedes utilizar Moonlight en lugar de Silverlight, aunque no he jugado mucho con él.
Una cosa más desde que preguntaste sobre Java. He encontrado algunas veces que el mundo de Java tenía bibliotecas para las que no podía encontrar equivalentes en el mundo .NET. En estos casos, he tenido una suerte increíble usando IKVM.NET para integrar esto en mis aplicaciones Mono. IKVM.NET también funciona en .NET, pero Mono e IKVM.NET son muy acogedores e incluso comparten algunos códigos.
Así que ahí tienes, una respuesta real para ti al menos.
Dice que debería poder compilar en una plataforma y ejecutar en cualquier lugar. Mi pregunta para ti es por qué piensas eso. ¿Cómo se puede aprovechar al máximo el procesamiento de 64 bits y las externsiones X86 si se está compilando en un bytecode genérico? Por otro lado, las compilaciones C/C++ y las bibliotecas con un sistema de compilación decente como CMake pueden compilarse para beneficiarse de las optimizaciones de silicio nativas. En el otro lado de la moneda, si quieres una verdadera portabilidad y facilidad de uso sin preocuparte por el mejor rendimiento, Python te atenderá mejor. Solo digo. – SpliFF
¿Qué tipo de ayuno necesitas? ¿Rápido para una aplicación de escritorio/rápido para un juego 3d multiusuario? Si quisiera una plataforma rápida y multiplataforma, elegiría C/C++ – Woody
@SpliFF: un buen compilador just-in-time alimentado desde un lenguaje intermedio decente debería poder aprovechar todo el procesamiento de 64 bits y las extensiones X86 necesarias. Sin embargo, alimentar a los clientes en múltiples ubicaciones en múltiples arquitecturas, y es molesto tener que compilar para cada uno. También hace la distribución más difícil.Me encanta Python, pero es demasiado lento para las tareas que estoy haciendo (correlaciones con 2GB-4GB de elementos). – vy32