Le framework Mono est une implémentation libre de l’environnement .NET de Microsoft. Miguel de Icaza, son principal développeur, vient d’annoncer la disponibilité de la version 3.0.
Un alignement important avec .NET 4.5
Mono 3.0 est tout d’abord aligné avec la dernière révision de .NET, à savoir la mouture 4.5 fournie notamment avec Windows 8. Cela lui permet de récupérer la nouveauté la plus importante de .NET, le développement asynchrone. Utilité ? Il permet par exemple à une application de différer une réponse attendue pour attendre avant la fin d'un calcul particulier. Ladite application peut donc continuer à effectuer d’autres actions pendant ce temps. Le compilateur de Mono utilise d’ailleurs par défaut le profil .NET 4.5 Async API, bien que les autres restent disponibles.
À propos, le compilateur C# est maintenant unifié pour l’ensemble des profils. En outre, et bien qu’il soit lui-même 32 bits, il permet maintenant de compiler des applications 64 bits pour OS X. Sur le système d’Apple, les développeurs pourront se servir également du langage fonctionnel F# en version 3.0, tandis que les applications iOS pourront enfin utiliser les API de chiffrement du système pour le stockage sécurisé des données.
Mono 3.0 intègre également la pile open source de Microsoft pour le développement web. Cela inclut :
- ASP.NET MVC 4
- ASP.NET WebPages
- Entity Framework
- Razor
- System.Json
Ce dernier remplace officiellement la propre implémentation de Mono présente dans les versions précédentes de l’environnement.
Un garbage collector largement amélioré
De nombreuses améliorations ont en outre été portées au ramasse-miettes (garbage collector) SGen. Rappelons tout d’abord qu’un ramasse-miettes sert à collecter les zones de mémoire qui ne sont plus utilisées par les applications afin de les libérer. Il s’agit donc d’un composant essentiel dans l’environnement .NET et d’autres.
Avec Mono 3.0, plusieurs ajouts importants font leur apparition :
- SGen peut distribuer ses tâches sur les cœurs supplémentaires du processeur quand il y a en a, ce qui peut mener à une hausse importante des performances
- Une amélioration du support des plateformes déjà prises en charge, avec par exemple sous OS X l’utilisation des API kernel Mach pour accélérer certaines opérations
- Un portage vers les plateformes Windows 32 bits et MIPS
Miguel de Icaza évoque aussi d'autres améliorations générales. Parmi les grands chantiers initiés dans Mono 3.0, on notera cependant que les développements futurs devraient être accélérés. Puisque l’environnement est basé sur .NET, il existe toujours en effet un décalage avec la « source ». Les nouveautés devraient en théorie prendre moins de temps à implémenter.
Mono 3.0 est toujours proposé pour Windows, OS X, les distributions Linux ainsi que Solaris. Attention cependant : la nouvelle mouture n’est pour l’instant disponible que sous la forme d’une archive de 40 Mo contenant les sources. Les environnements précompilés en sont toujours à la mouture 2.10 et seule une version OS X bêta de Mono 3.0 est accessible. Ceux qui ne sont pas intéressés par les sources devront donc attendre encore un peu.
Pour découvrir d'avantage les nouveautés de Mono 3.0, on consultera les notes complètes de version depuis le site officiel.
Commentaires (47)
#1
Ça intéresse encore des gens ce truc ?
#2
Question peut-être bête:
Cela permettra - t-il une meilleure implémentation des applis en .NET sous Linux?
#3
#4
Chapeau
" />
Ils font vraiment du bon boulot sur ce projet, ils arrivent toujours à suivre les versions de .NET avec très peu de retard. Et sur cette version, c’était clairement pas évident, l’implémentation de async/await dans le compilateur est loin d’être triviale
#5
#6
#7
Donc Mono fonctionne sous Windows XP et Vista, mais .NET 4.5 non ? où est la logique là dedans ?
#8
#9
J’ai pas compris. C’est
#10
#11
#12
#13
#14
#15
Cool
" />
#16
#17
Tant qu’il seront pas foutu de porter WPF, je ne serai pas intéressé ( je conçois que c’est assez hard de faire un WPF portable )
#18
Il faut arrêter de dire que Mono suit (de près ou de loin) les version de .Net.
Ils n’en sont même pas à une implémentation complète de .Net 1.0 (sortie en quoi, 2002 ? 2003 ?).
Ils font le tri dans ce qui les intéresse et l’implémente. Tout le reste, ils s’en balance. En gros, 80% part à la poubelle à chaque nouvelle version, et 20% est implémenté (avec un retard comprit entre 6 mois et 2 ans… tu m’étonnes qu’ils veulent accélérer !). Ceci rend Mono quasi inutilisable en entreprise, ou on doit pouvoir répondre à tous les besoins. Avec .Net de MS c’est pas toujours super évident (y a toujours des trucs qu’ils n’ont pas prévu et où il faut un peu tordre la plateforme), avec Mono c’est un gageur…
Donc oui, des projets utilise Mono, mais non, ça n’est pas rentable (en tout cas dès qu’on sort des clous décidé par Miguel, ce qui arrive rapidement quand on a de vrai clients en face qui ont toujours au moins un besoin tordu dans leur outil), donc seule une volonté inébranlable de faire du 100% libre justifie l’utilisation de Mono, et la frustration que cela va engendrer (ou chez le client qui n’aura pas sa fonctionnalité tordue, ou chez l’équipe de développement qui va se faire allumé pour avoir mit 3 mois à implémenter une petite fonctionnalité de rien du tout, ou qui aura des problèmes de perfs qui nécessitera une upgrade du parc de machines de l’entreprise…).
Bref, Mono c’est cool pour un projet d’étude, mais dès le premier stage en entreprise, tu comprends ta douleur :)
#19
async await est une super fonctionnalité de .NET 4.5 Dire Pour moi, ca en fait un des meilleurs langages pour faire des applications web non bloquantes coté serveur, devant node.js, parce que les promises, ben c’est gentil mais:
avec MVC4/WebAPI, tu peux faire des Actions asynchrones, SignalR est aussi conçu pour être entièrement non bloquant:
public async Task GetTruc(int id)
{
return await repository.Get(id);
}
ne bloquera pas un thread de requête pendant l’appel à la Base de donnée distante. Et vu que dans une appli normale, les threads passent quasiment tout leur temps à attendre que des requêtes IO style base de donnée, cela decuple les capacités du serveur web.
Coté client, ca simplifie fortement l’ecriture de logiques complexes qui ne font pas bloquer l’interface utilisateur. (genre des requêtes web parallelles suivies d’un travail intensif sur un thread de fond )
Pour ce qui est de la complexité d’implementation, il faut gerer des choses comme celle-ci:
while(true)
{
await Task.Delay(1000);
}
Il faut bien comprendre que dans le cas ci-dessus, le thread executant le programme est bien relaché pendant l’attente de 1000ms. Il n’est pas bloqué, contrairement à un thread.Sleep(1000);
#20
En fait, Mono est fait pour:
#21
#22
#23
Je développe une application sur MonoTouch au boulot (Mono implémenté sur iPhone) et j’aime beaucoup. Les applications sont très rapide, et je trouve ça bien plus agréable à dev que l’Objective C.
#24
Dans la famille usine à gaz méga-brain fuckage… on a déjà java, merci on souffre suffisamment.
#25
#26
En tout cas je suis bien content d’avoir Mono pour faire exécuter quelques programmes en ligne de commandes que je développe et que je compile avec VS. C’est beaucoup plus rapide que de faire ça à la façon homme des cavernes en C avec vim.
Si c’est un IDE que tu cherches, il y en a un paquet sous Linux. Rien ne t’oblige à faire “l’homme des cavernes”…
#27
#28
Modo Alert:
" />
Risque de fight pro/anti vim
#29
#30
#31
#32
#33
Ce genre d’amélioration dans le code sont appréciables à utiliser mais le problème c’est que chacun les proposent un peu à leur sauce, du coup, utiliser massivement ces astuces permettant une meilleure lecture enferme le développeur dans sa techno.
C’est vraiment flagrant dans les langages où l’introspection est aisée : on peut créer des comportements via des mots clé ou des annotations de toutes sortes qui vont agir profondément en plus du code de telle sorte qu’il devient difficile d’en suivre la logique sans être un expert ou un vieux de la vieille qui a tout mis en place.
Selon moi, ce genre d’améliorations relèvent du genre de bidouilles simplificatrices que certains ont cru apporter à coup de ‘goto’.
#34
#35
#36
#37
#38
#39
La v3.0 est sorti, ok.
Mais pourquoi sur la page download, seul une version BETA OSX est disponible ? Trop fatigué après avoir dev pour mettre à jour le site ?
#40
#41
#42
#43
#44
Beeuark !
Le fait que ça vienne de Lisp ne m’étonne pas, finalement. Ça explique pourquoi la syntaxe est tellement décalée par rapport au reste du langage.
Je cite wikipedia
Le langage LISP dispose d’une syntaxe très simple et élégante, utilisant un minimum de concepts. Cette économie de concepts mène Gregory Chaitin à qualifier cette syntaxe de « joyau de splendeur mathématique et de beauté intellectuelle austère »4.
Bah voilà, lorsqu’on me promet une syntaxe issue d’un joyau de splendeur mathématique et de beauté intellectuelle austère, je me prédit que la lecture du code va être une partie de plaisir.
Surtout lorsqu’elle est mélangée à une autre syntaxe, beaucoup plus verbeuse et terre à terre, et probablement pas élégante mathématiquement pour deux sous.
#45
#46
#47