¿Cuántas menos bibliotecas hay para Mono que para Java?

Carezco de la descripción general de ambas alternativas, pero tengo bastante libertad de elección para mi próximo proyecto. Estoy buscando datos técnicos concretos en las áreas de

• rendimiento (por ejemplo, me dijeron que Java es bueno para subprocesos y escuché que la optimización del código en tiempo de ejecución se ha vuelto muy buena recientemente para .NET)
• portabilidad en el mundo real (ambos están destinados a ser portátiles, ¿qué Catch-22 para cada uno?)
• disponibilidad de herramientas ( CI , automatización de compilación, depuración, IDE)

Estoy buscando especialmente lo que realmente experimentaste en tu propio trabajo en lugar de las cosas que podría buscar en Google. Mi aplicación sería un servicio de back-end que procesa grandes cantidades de datos de series de tiempo.

Mi principal plataforma de destino sería Linux.

Editar: Para formular mi pregunta de manera más adecuada, estoy interesado en todo el paquete (bibliotecas de terceros, etc.), no solo en el idioma. Para las bibliotecas, eso probablemente se reduce a la pregunta "¿cuántas menos bibliotecas hay para Mono que para Java"?

Para su información, desde entonces he elegido Java para este proyecto, porque parecía más desgastado por la batalla en el lado de la portabilidad y también ha existido por un tiempo en sistemas más antiguos. Estoy un poco triste por eso, porque tengo mucha curiosidad por C # y me encantaría haber hecho un gran proyecto en él, pero tal vez la próxima vez. Gracias por todos los consejos.

Bueno ... Java es en realidad más portátil. Mono no está implementado en todas partes y está muy por detrás de la implementación de Microsoft. El SDK de Java parece estar mejor sincronizado en todas las plataformas (y funciona en más plataformas).

También diría que Java tiene más herramientas disponibles en todas esas plataformas, aunque hay muchas herramientas disponibles para .NET en plataformas Windows.

Actualización para 2014

Todavía mantengo esta opinión en 2014. Sin embargo, calificaré esto diciendo que recién ahora estoy comenzando a prestarle algo de atención a Mono después de un largo tiempo sin importarme realmente, por lo que puede haber mejoras en el tiempo de ejecución de Mono (o ecosistema ) que no me han informado. AFAIK, todavía no hay soporte para WPF, WCF, WF, de WIF. Mono puede ejecutarse en iOS, pero que yo sepa, el tiempo de ejecución de Java aún se ejecuta en muchas más plataformas que Mono. Además, Mono está comenzando a ver algunas herramientas mucho mejoradas (Xamarin), y Microsoft parece tener una actitud mucho más multiplataforma y la voluntad de trabajar con socios para hacerlos complementarios, en lugar de competitivos (por ejemplo, Mono será una parte bastante importante del próximo panorama OWIN / Helios ASP.NET). Sospecho que en los próximos años las diferencias en portabilidad disminuirán rápidamente,

Actualización para 2018

Mi punto de vista sobre esto está comenzando a ir en sentido contrario. Creo que .NET, en general, particularmente con .NET Core, ha comenzado a lograr una "paridad de portabilidad" con Java. Se están realizando esfuerzos para llevar WPF a .NET Core para algunas plataformas, y .NET Core en sí se ejecuta ahora en muchas plataformas. Mono (propiedad de Xamarin, que ahora es propiedad de Microsoft) es un producto más maduro y pulido que nunca, y la escritura de aplicaciones que funcionan en múltiples plataformas ya no es el dominio de la gnosis profunda de la piratería .NET, pero es un esfuerzo relativamente sencillo. . Por supuesto, existen bibliotecas, servicios y aplicaciones que son solo para Windows o solo pueden apuntar a plataformas específicas, pero lo mismo puede decirse de Java (en términos generales).

Si estuviera en el lugar del OP en este punto, no puedo pensar en ninguna razón inherente a los lenguajes o las pilas de tecnología que me impidan elegir .NET para cualquier aplicación que se desarrolle a partir de este punto.

Mono hace un mejor trabajo al apuntar a las plataformas que quiero admitir. Aparte de eso, todo es subjetivo.

Comparto código C # en las siguientes plataformas: - iOS (iPhone / iPad) - Android - La Web (HTML5) - Mac (OS X) - Linux - Windows

Podría compartirlo en más lugares: - Windows Phone 7 - Wii - XBox - PS3 - etc.

Lo más importante es iOS, ya que MonoTouch funciona fantásticamente. No conozco ninguna buena forma de apuntar a iOS con Java. No puedes apuntar a Windows Phone 7 con Java, por lo que diría que los días en que Java era mejor para dispositivos móviles han quedado atrás.

Sin embargo, el factor más importante para mí es la productividad personal (y la felicidad). C # como lenguaje está años por delante de Java en mi humilde opinión y el marco .NET es un placer de usar. La mayor parte de lo que se agrega en Java 7 y Java 8 ha estado en C # durante años. Sin embargo, los lenguajes JVM como Scala y Clojure (ambos disponibles en CLR) son bastante buenos.

Veo a Mono como una plataforma por derecho propio (excelente) y trato a .NET como la implementación de Microsoft de Mono en Windows. Esto significa que primero desarrollo y pruebo en Mono. Esto funciona de maravilla.

Si tanto Java como .NET (digamos Mono) fueran proyectos de código abierto sin ningún respaldo corporativo, elegiría Mono sobre Java cada vez. Creo que es una plataforma mejor.

Tanto .NET / Mono como la JVM son excelentes opciones, aunque personalmente usaría algún otro lenguaje que no sea Java en la JVM.

Mi opinión sobre algunos de los otros comentarios:

Problema: rendimiento.

** Respuesta: Tanto la JVM como la CLR funcionan mejor que lo que dicen los detractores. Diría que la JVM funciona mejor. Mono es generalmente más lento que .NET (aunque no siempre).

Yo personalmente tomaría ASP.NET MVC sobre J2EE cualquier día, tanto como desarrollador como como usuario final. El soporte para Google Native Client también es bastante bueno. Además, sé que se supone que el bajo rendimiento de la GUI para las aplicaciones Java de escritorio es cosa del pasado, pero sigo encontrando aplicaciones lentas. Por otra parte, podría decir lo mismo de WPF. GTK # es bastante rápido, por lo que no hay razón para que sean lentos.

Problema: Java tiene un ecosistema más amplio de bibliotecas disponibles.

Respuesta: Probablemente sea cierto, pero en la práctica no es un problema.

Prácticamente todas las bibliotecas de Java (incluido el JDK) se ejecutan perfectamente en .NET / Mono gracias a IKVM.NET . Esta pieza de tecnología es una verdadera maravilla. La integración es asombrosa; puede usar una biblioteca Java como si fuera nativa. Sin embargo, solo he tenido que usar bibliotecas Java en una aplicación .NET. El ecosistema .NET / Mono generalmente ofrece más de lo que necesito.

Problema: Java tiene un mejor (más amplio) soporte de herramientas

Respuesta: no en Windows. De lo contrario, estoy de acuerdo. Sin embargo, MonoDevelop es bueno.

Quiero dar un saludo a MonoDevelop ; es una joya. MonoDevelop integra la mayoría de las herramientas que quiero usar, incluida la finalización de código (intellisense), la integración de Git / Subversion, el soporte para pruebas unitarias, la integración de SQL, la depuración, la fácil refactorización y la exploración de ensamblajes con descompilación sobre la marcha. Es maravilloso usar el mismo entorno para todo, desde la web del lado del servidor hasta las aplicaciones móviles.

Problema: compatibilidad entre plataformas.

Respuesta: Mono es una base de código única en todas las plataformas, incluido Windows.

Desarrolle primero para Mono e impleméntelo en .NET en Windows si lo desea. Sin embargo, si compara .NET de MS con Java, Java tiene la ventaja en términos de coherencia entre plataformas. Ver siguiente respuesta ...

Problema: Mono se retrasa .NET.

Respuesta: No, no es así. En mi humilde opinión, esta es una declaración a menudo declarada pero incorrecta.

La distribución Mono de Xamarin se envía con C #, VB.NET, F #, IronPython, IronRuby y creo que tal vez Boo fuera de la caja. El compilador Mono C # está completamente actualizado con MS. El compilador Mono VB.NET se retrasa con respecto a la versión de MS. Los otros compiladores son los mismos en ambas plataformas (al igual que otros lenguajes .NET como Nemerle, Boo y Phalanger (PHP)).

Mono se envía con gran parte del código escrito de Microsoft, incluido Dynamic Language Runtime (DLR), Managed Extensibility Framework (MEF), F # y ASP.NET MVC. Debido a que Razor no es de código abierto, Mono actualmente se envía con MVC2, pero MVC3 funciona bien en Mono.

La plataforma principal Mono ha seguido el ritmo de .NET durante muchos años y la compatibilidad es impresionante. Puede usar el lenguaje C # 4.0 completo e incluso algunas características de C # 5.0 hoy. De hecho, Mono a menudo lidera .NET de muchas maneras.

Mono implementa partes de la especificación CLR que ni siquiera Microsoft admite (como matrices de 64 bits). Una de las nuevas tecnologías más interesantes del mundo .NET es Rosylyn . Mono ha ofrecido el compilador de C # como servicio durante muchos años. Algunas de las ofertas de Rosylyn también están disponibles a través de NRefractory . Un ejemplo de dónde Mono todavía está por delante serían las instrucciones SIMD para acelerar el rendimiento de los juegos.

Microsoft ofrece una serie de productos además de .NET que no están disponibles en Mono, de donde proviene la idea errónea sobre el retraso Mono. Windows Presentation Foundation (WPF), Entity Framework (EF), WCF (Windows Communication Foundation) son ejemplos de productos que no funcionan o no son compatibles con Mono. La solución obvia es utilizar alternativas multiplataforma como GTK #, NHibernate y ServiceStack.

Problema: Microsoft es malvado.

Respuesta: Verdadero. Y qué.

Mucha gente ofrece las siguientes razones para evitar el uso de Mono:

1) No debe usar Mono porque debe evitarse la tecnología de Microsoft

2) Mono apesta porque no te permite usar todas las tecnologías que ofrece Microsoft

Para mí, está claro que estas declaraciones son incompatibles. Rechazo la primera declaración, pero omitiré ese argumento aquí. La segunda afirmación es cierta para todas las alternativas de .NET.

La JVM es una gran plataforma y la explosión de lenguajes JVM es asombrosa. Usa lo que te haga feliz. Por ahora, eso es a menudo .NET / Mono para mí.

De hecho, desarrollo en .NET, ejecuto todas mis pruebas primero en Mono y luego en Windows. De esa manera sé que mis aplicaciones son multiplataforma. Lo he hecho con mucho éxito en aplicaciones ASP.NET y Winforms.

No estoy seguro de dónde algunas personas tienen la impresión de que Mono es tan horrible, pero ciertamente ha hecho su trabajo en mis casos y opiniones. Es cierto que tendrá un poco de retraso para los últimos y mejores inventos en .NET world, pero hasta ahora, .NET 2.0 en Windows y Linux es muy sólido para mí.

Tenga en cuenta que obviamente hay muchas peculiaridades en esto, pero la mayoría de ellas provienen de asegurarse de que está escribiendo código portátil. Si bien los marcos hacen un gran trabajo al abstraer el sistema operativo en el que está ejecutando, las pequeñas cosas como la distinción entre mayúsculas y minúsculas de Linux en las rutas y los nombres de archivos requieren un poco de tiempo para acostumbrarse, al igual que cosas como los permisos.

.NET es definitivamente muy multiplataforma debido a Mono basado en mis experiencias hasta ahora.

Java en realidad es tan multiplataforma como todo el mundo dice. Existe una implementación de JVM para casi cualquier sistema operativo convencional (incluso Mac OS X, finalmente), y todos funcionan muy bien. Y hay toneladas de herramientas de código abierto que son igualmente multiplataforma.

El único problema es que hay ciertas operaciones nativas que no se pueden realizar en Java sin escribir algunas DLL o SO. Es muy raro que surjan en la práctica. En todos esos casos, sin embargo, he podido evitarlo generando procesos nativos y raspando la pantalla de los resultados.

Creo que la pregunta está redactada incorrectamente. C # vs.Java es mucho menos interesante en términos de uso multiplataforma que (a) qué plataformas necesita admitir y (b) considerando las bibliotecas centrales y las bibliotecas de terceros disponibles. El idioma es casi la parte menos importante del proceso de toma de decisiones.

Java es una mejor opción para el desarrollo multiplataforma.

• Actuación. Java y .Net tienen un nivel de rendimiento similar debido a la máquina virtual, pero JVM normalmente tiene un mejor rendimiento debido a años y años de optimización.

• Biblioteca. Aunque esto depende de su tarea, Java tiene muchas más bibliotecas de código abierto o de terceros disponibles allí. Para aplicaciones de servidor, J2EE, Spring, Struts, etc. Para GUI, aunque .Net proporciona API de capa Win32 pero esto causa problemas de compatibilidad. Java tiene Swing, SWT, AWT, etc. Funciona en la mayoría de los casos.

• Compatibilidad. Estos son los aspectos clave que deben tenerse en cuenta al desarrollar el programa multiplataforma. Dos cuestiones: primero, la compatibilidad de la plataforma. Java sigue ganando ya que JDK está bien mantenido por la empresa única y original Sun. MS no mantiene mono, por lo que aún no tiene garantía de compatibilidad con la actualización. 2. Compatibilidad con versiones anteriores. Sun mantiene una buena reputación en su compatibilidad con versiones anteriores, aunque a veces esto parece demasiado rígido y ralentiza el ritmo.

• Herramientas. Java tiene buenos IDE multiplataforma. Netbeans, Eclipse, etc. La mayoría de ellos son gratuitos. VS Studio es bueno pero solo en Windows, y no cuesta nada. Ambos proporcionan buenas pruebas unitarias, depuraciones, perfiles, etc.

Por lo tanto, sugeriría que Java es una mejor opción. Como ejemplo, hay algunas aplicaciones multiplataforma de escritorio famosas desarrolladas por Java: Vuze, Limewire, BlogBridge, CrossFTP, por no mencionar esos IDE. En cuanto a .Net, tengo un conocimiento limitado sobre estas aplicaciones exitosas.

He estado haciendo la misma pregunta tarde y en mi humilde opinión, .NET / Mono parece ser una mejor opción simplemente porque Mono tiene un gran historial de aplicaciones de escritorio multiplataforma (a diferencia de Java) y, por supuesto, Mono es mejorando a pasos agigantados en estos días.

Voy a decir Java también. Si lo mira en términos de madurez, Sun (y otros) ha invertido mucho más tiempo y esfuerzo en lograr que la JVM funcione en plataformas que no son Windows.

En contraste, Mono es definitivamente un ciudadano de segunda clase en el ecosistema .NET.

Dependiendo de quiénes sean sus clientes objetivo, también puede encontrar que existe un retroceso real contra el uso de Mono: ¿Novell ofrece el mismo tipo de soporte de proveedor para Mono que usted obtendría para Java o .NET en Windows?

Si su objetivo principal es el alojamiento de su servicio en Windows, tendría sentido considerar esta opción, pero dado que se dirige principalmente a Linux, me parece una obviedad.

Java fue diseñado para ser multiplataforma; C # /. Net no lo era. En caso de duda, utilice la herramienta que fue diseñada para su propósito.

EDITAR: para ser justos, .NET fue diseñado para funcionar en entornos embebidos / PC / Server, por lo que es un TIPO de multiplataforma. Pero no fue diseñado para Linux.

Creo que la respuesta es "depende". Java se ejecuta en casi cualquier cosa, pero .NET / Mono son (en mi humilde opinión) un mejor marco para el escritorio. Así que supongo que la respuesta realmente depende de las plataformas a las que planeas apuntar.

Para agregar un poco más a la conversación, Java es más portátil si te quedas con una versión atrás: Java 5 todavía tiene muchas características excelentes, por lo que puedes esperar a Java 6 y aún tienes mucho rango en términos de lenguaje y bibliotecas para desarrollar. con. Mac es la plataforma principal que puede tardar algún tiempo en ponerse al día con la última versión de Java.

Java también tiene un excelente cuerpo de estándares que hace crecer la plataforma de manera inteligente en función de las aportaciones de muchas empresas diferentes. Esta es una característica que a menudo se pasa por alto, pero mantiene incluso las nuevas características funcionando bien en múltiples plataformas y proporciona una gran variedad de soporte de biblioteca para algunas cosas esotéricas (como extensiones opcionales).

Yo votaría por que Java sea más portátil que C #. Java definitivamente también tiene un conjunto muy rico de bibliotecas estándar. También existe un amplio conjunto de bibliotecas de terceros de código abierto, como las proporcionadas por el proyecto Jakarta ( http://jakarta.apache.org/ ).

También existen todos los sospechosos habituales para CI, pruebas unitarias, etc. El soporte IDE multiplataforma también es muy bueno con Eclipse, Netbeans, IntelliJ IDEA, etc.

También hay otras opciones de idioma. Me he aficionado bastante a Python, que funciona bien en Windows, Linux y Mac, y tiene un amplio conjunto de bibliotecas.

Si bien Mono tiene su parte de problemas , creo que tiene una mejor historia de compatibilidad multiplataforma, especialmente si confía en la invocación de la plataforma nativa.

No hay suficientes palabras en Stack Overflow para enfatizar cuánto más suave es obtener algo nativo llamado y ejecutado en .NET / Mono en (al menos en mi experiencia 3 ...) múltiples plataformas frente al esfuerzo equivalente de Java.

Gatorhall , ¿tienes algunos datos para respaldar eso?

Actuación. Java y .Net tienen un nivel de rendimiento similar debido a la máquina virtual, pero JVM normalmente tiene un mejor rendimiento debido a años y años de optimización.

Antecedentes: soy un tipo de Windows desde Windows 3.1 y actualmente soy un usuario de Linux (todavía ejecuto Windows 7, excelente sistema operativo, en una máquina virtual para Visual Studio 2010 y otras herramientas).

El punto: yo y muchos usuarios (Windows, Linux, etc.) que conozco, podemos no estar de acuerdo con usted. Java tiende a funcionar más lento incluso en una aplicación de escritorio Linux, ASP.NET funciona más rápido que las páginas del servidor Java muchas veces. Algunos pueden estar de acuerdo en que incluso PHP no compilado funciona mejor en varios escenarios.

¿Java es más multiplataforma? No tengo ninguna duda sobre esto (la historia de aquí en adelante), pero más rápido (sin decir que .NET lo es) no es tan seguro y me gustaría ver algunos puntos de referencia reales.