Mono cible mieux les plates-formes que je souhaite prendre en charge. A part ça, tout est subjectif.
Je partage du code C # sur les plates-formes suivantes: - iOS (iPhone / iPad) - Android - Le Web (HTML5) - Mac (OS X) - Linux - Windows
Je pourrais le partager encore plus d'endroits: - Windows Phone 7 - Wii - XBox - PS3 - etc.
Le biggie est iOS depuis MonoTouch fonctionne à . Je ne connais aucun bon moyen de cibler iOS avec Java. Vous ne pouvez pas cibler Windows Phone 7 avec Java, donc je dirais que l'époque où Java était meilleur pour les mobiles est derrière nous.
Le facteur le plus important pour moi est la productivité personnelle (et le bonheur). C # en tant que langage a des années d'avance sur Java IMHO et le framework .NET est un plaisir à utiliser. La plupart de ce qui est ajouté dans Java 7 et Java 8 l'est en C # depuis des années. Les langages JVM comme Scala et Clojure (tous deux disponibles sur le CLR) sont cependant assez sympas.
Je vois Mono comme une plate-forme à part entière (une excellente) et je considère .NET comme l'implémentation Microsoft de Mono sur Windows. Cela signifie que je développe et teste d'abord sur Mono. Cela fonctionne à merveille.
Si Java et .NET (disons Mono) étaient des projets Open Source sans aucun support d'entreprise, je choisirais Mono plutôt que Java à chaque fois. Je pense que c'est simplement une meilleure plateforme.
.NET / Mono et la JVM sont d'excellents choix, même si j'utiliserais personnellement un autre langage que Java sur la JVM.
Mon avis sur certains des autres commentaires:
Problème: performances.
** Réponse: La JVM et le CLR fonctionnent mieux que ce que disent leurs détracteurs. Je dirais que la JVM fonctionne mieux. Mono est généralement plus lent que .NET (mais pas toujours).
Personnellement, je prendrais ASP.NET MVC sur J2EE tous les jours en tant que développeur et utilisateur final. La prise en charge de Google Native Client est également très intéressante. De plus, je sais que les mauvaises performances de l'interface graphique pour les applications Java de bureau sont censées appartenir au passé, mais je continue à en trouver des lentes. Là encore, je pourrais dire la même chose pour WPF. GTK # est très rapide, donc il n'y a aucune raison pour laquelle ils doivent être lents.
Problème: Java dispose d'un plus grand écosystème de bibliothèques disponibles.
Réponse: Probablement vrai, mais ce n'est pas un problème dans la pratique.
Pratiquement toutes les bibliothèques Java (y compris le JDK) ne fonctionnent que dandy sur .NET / Mono grâce à IKVM.NET . Cette pièce de technologie est une vraie merveille. L'intégration est incroyable; vous pouvez utiliser une bibliothèque Java comme elle était native. Cependant, je n'ai eu à utiliser que les bibliothèques Java dans une seule application .NET. L'écosystème .NET / Mono offre généralement plus que ce dont j'ai besoin.
Problème: Java a une meilleure prise en charge des outils (plus larges)
Réponse: pas sous Windows. Sinon je suis d'accord. MonoDevelop est bien cependant.
Je tiens à remercier MonoDevelop ; c'est un bijou. MonoDevelop intègre la plupart des outils que je souhaite utiliser, y compris la complétion de code (intellisense), l'intégration Git / Subversion, la prise en charge des tests unitaires, l'intégration SQL, le débogage, la refactorisation facile et la navigation d'assemblage avec décompilation à la volée. Il est merveilleux d'utiliser le même environnement pour tout, du Web côté serveur aux applications mobiles.
Problème: compatibilité entre les plates-formes.
Réponse: Mono est une base de code unique sur toutes les plates-formes, y compris Windows.
Développez d'abord pour Mono et déployez-le sur .NET sous Windows si vous le souhaitez. Si vous comparez .NET de MS à Java, Java a l'avantage en termes de cohérence entre les plates-formes. Voir la réponse suivante ...
Problème: Mono est à la traîne .NET.
Réponse: Non, ce n'est pas le cas. IMHO, c'est une déclaration souvent déclarée mais incorrecte.
La distribution Mono de Xamarin est fournie avec C #, VB.NET, F #, IronPython, IronRuby et je pense que Boo est peut-être prêt à l'emploi. Le compilateur Mono C # est complètement à jour avec MS. Le compilateur Mono VB.NET est en retard par rapport à la version MS. Les autres compilateurs sont les mêmes sur les deux plates-formes (comme le sont d'autres langages .NET comme Nemerle, Boo et Phalanger (PHP)).
Mono est livré avec une grande partie du code écrit de Microsoft, y compris le Dynamic Language Runtime (DLR), Managed Extensibility Framework (MEF), F # et ASP.NET MVC. Parce que Razor n'est pas Open Source, Mono est actuellement livré avec MVC2 mais MVC3 fonctionne très bien sur Mono.
La plate-forme principale Mono a suivi le rythme de .NET ou de nombreuses années et la compatibilité est impressionnante. Vous pouvez utiliser le langage C # 4.0 complet et même certaines fonctionnalités C # 5.0 aujourd'hui. En fait, Mono dirige souvent .NET de plusieurs manières.
Mono implémente des parties de la spécification CLR que même Microsoft ne prend pas en charge (comme les tableaux 64 bits). L'une des nouvelles technologies les plus intéressantes du monde .NET est Rosylyn . Mono propose le compilateur C # en tant que service depuis de nombreuses années. Une partie de ce que propose Rosylyn est également disponible via NRefractory . Les instructions SIMD pour accélérer les performances de jeu sont un exemple où Mono est toujours en avance.
Microsoft propose un certain nombre de produits en plus de .NET qui ne sont pas disponibles en Mono, d'où vient l'idée erronée du retard Mono. Windows Presentation Foundation (WPF), Entity Framework (EF), WCF (Windows Communication Foundation) sont des exemples de produits qui ne fonctionnent pas ou sont mal pris en charge sur Mono. La solution évidente consiste à utiliser à la place des alternatives multiplateformes telles que GTK #, NHibernate et ServiceStack.
Problème: Microsoft est diabolique.
Réponse: vrai. Et alors.
De nombreuses personnes invoquent les raisons suivantes pour éviter d'utiliser Mono:
1) Vous ne devez pas utiliser Mono car la technologie Microsoft doit être évitée
2) Mono est nul car il ne vous permet pas d'utiliser toutes les technologies proposées par Microsoft
Pour moi, il est clair que ces déclarations sont incompatibles. Je rejette la première déclaration, mais je vais sauter cet argument ici. La deuxième déclaration est vraie pour toutes les alternatives .NET.
La JVM est une excellente plate-forme et l'explosion des langages JVM est impressionnante. Utilisez ce qui vous rend heureux. Pour l'instant, c'est souvent .NET / Mono pour moi.