La sortie de Mono 4.0 a été officiellement annoncée ce mois-ci. Ceci constitue la première version contenant du code open source provenant du projet CoreCLR de Microsoft. Mono 4.0 propose C# 6 par défaut, ce qui signifie une fois encore que Mono propose une version RTM d’un nouveau compilateur C# avant Microsoft.
En plus des fonctionnalités et changements sur lesquels nous avons précédemment communiqué, Mono 4 est supposé avoir un "overhead induit par le debugger plus léger" et est censé offrir un "support des machines Basic PowerPC64 LE". Les détails spécifiques de ces fonctionnalités ne sont pas disponibles pour le moment.
De nombreuses personnes ont demandé pourquoi le projet Mono devrait continuer, maintenant que Microsoft travaille sur son propre CLR open source et multiplateforme. alexrp, contributeur Mono et utilisateur reddit, explique :
Je pense que les gens n’ont pas le bon état d’esprit quant à la situation Mono/CoreCLR. Pourquoi le fait qu’une VM deviendrait open source et serait portée sur d’autres OS signifierait qu’il n’y aurait plus de place pour d’autres VM ? Cela reviendrait à dire qu’il ne devrait y avoir qu’une implémentation de Python, ou qu’une seule JVM. Ce n’est pas une bonne chose, la compétition est saine.
Il se trouve que Mono propose beaucoup de fonctionnalités que CoreCLR ne propose pas : LLVM, full AOT (compilation Ahead Of Time), NaCl (Native Client), tasklets, un bridge GC cross-VM, divers modules de profiling, etc. Le temps de démarrage de Mono et l’empreinte mémoire du runtime sont aussi optimisés pour des plateformes et des terminaux qui ne font (du moins actuellement) même pas partie des cibles de CoreCLR. D’un autre côté, CoreCLR a un GC plus mature et globalement une meilleure génération de code (d’où le temps de démarrage plus long). Les deux VM ont leurs points forts et il n’y a aucune raison que les deux ne puissent pas exister.
Ce n’est pas que nous insistions pour garder notre propre code non plus. Nous sommes heureux de basculer sur des parties de code CoreCLR lorsqu’il y a un bénéfice clair à le faire (moins de maintenance, plus correct, suffisamment portable). Nous avons déjà importé des tonnes de code de référence et nous importons aussi certaines parties de la VM CoreCLR :
https://github.com/mono/mono/blob/master/mono/metadata/decimal-ms.c https://github.com/mono/mono/blob/master/mono/metadata/threadpool-ms.c
La release 4.0 n’est pas sans présenter quelques défauts cependant. L’utilisateur reddit whatsinashagbox écrit :
Je ne suis pas certain de ce que je dois faire, puisque j’ai une application s’appuyant sur des dll tierces qui semblent requérir la version 10.0.0.0 de Microsoft.VisualBasic.dll et qui ne vont pas fonctionner sous mono 4. Les notes de version semblent dire qu’il existe un moyen de les faire utiliser l’assembly .Net 4.5, mais je ne vois pas comment faire. Quelqu’un a-t-il un idée sur la manière de faire fonctionner tout cela sous la nouvelle version de Mono ?
Ce point est actuellement en cours d’investigation et semble être ce que l’on appelle un accident.