Oui, MS travail sur le portage de WPF en .Net Native(c’est à dire la possibilité de se passer de la machine virtuel .Net et de l’installation de son framework), qui permettra d’en gros faire comme du Go (ou du C++, techniquement c’est la même chose).

 

 Et non, Gooom, CLRCore n’est pas de la poudre aux yeux, c’est une étape vers le .Net Native et la portativité. Ce n’est pas une fin en soit, c’est un moyen.

 

 De même pour ASP.Net, la version 5 est une réarchitecture complète (et recodage d’une grosse partie) on peut espérer que ça remette cette techno dans la course, car elle se traine effectivement de vieux problèmes… Normalement on devrait en avoir une première version exploitable en Novembre (pour WPF c’est repoussé à 2016).

Les postes clients lourds sont encore très largement en Windows, donc ils seraient en effet étonnant qu’ils allouent du budget sur la portabilité de WPF/WinForms.

 

Pour les client légers, où Android tient la corde (85% ? quelque chose comme ça…), ils ont l’air de s’en remettre à Xamarin. Je les vois pas concurrencer Xamarin tout de suite, ils semblent plutot coopérer (tant que aider Xamarin permettra d’arriver à la compatibilité .Net sur Android à un cout moindre que de le faire en interne, je pense qu’ils resteront sur cette solution).

 

 Il n’y a que sur les serveurs Web où les solutions Unix/Linux sont présentes sans avoir de réponse, d’où le portage IIS/ASP.Net et services sur Linux.

 

 Par contre .Net Native risque fort de se généraliser, ça à l’air de marcher comme ils veulent sur leur UWP (Win10) donc ils vont pouvoir enchainer si les language natif continuent à leur mettre la pression (et ça semble être la direction prise par tout le monde).

C’était un post du blog .Net sur la roadmap .Net, et l’auteur du post (un PM .Net) avait répondu dans les coms que le cas WPF était l’objectif de départ de .Net Native, puisque c’est le cas où le temps de démarrage (où l’absence de JIT peut faire le jour et la nuit) est le plus source de mécontentement (la faute à une mauvaise interop bien souvent…). Le .Net Native sur UWP n’est là encore qu’une étape pour arriver ensuite à WPF (qui est bien sur largement plus compliqué car plus souple, mais c’est la même techno).

 

Mais pour des raisons politiques, priorité a été mit sur la portabilité d’asp.net 5 (ça tient à cœur à Satya et consor), donc tant que c’est pas fait (et on verra pas la version final avant 2016) ils ne bosseront pas vraiment sur WPF (les équipes MS étant en vases communicants) donc on aura pas de date de sitôt malheureusement… En tout cas pas avant la BUILD 2016 m’est d’avis.

Gooom a écrit :



Je trouve cette réponse assez juste :http://stackoverflow.com/a/7480033

Je rajouterais aussi que l’autre différence à ne pas négliger est tout simplement la vitesse d’exécution et le nombre donc le cas d’utilisation et l’utilité. 

  





Je suis parfaitement d’accord avec cette très bonne réponse (mais peut-être un peu courte) pour ne pas être d’accord pour dire qu’il faut opposer Async/await à la façon dont Go fonctionne. Hors c’est bien ce que ton com précédent laissait à penser, ce à quoi je réagissais.



 Async/await est une façon d’injecter du concurrentielle dans du code non concurrentielle sans tout réarchitecturer. Mais ça, ça n’existe pas en Go, puisqu’il est partit dès le départ sur le coté concurrentielle (contrairement à .Net 1.0, ah que ça date !). Donc les opposer n’a pas de sens !

  

Si t’as envie de faire une archi concurrentielle en C#, proche de ce que tu ferait en Go, tu n’utiliseras pas Async/await. D’ailleurs, je dirais même que tu n’utiliseras pas beaucoup de C# : tu feras principalement du F#.

 

Le débat est donc plus vaste qu’une simple histoire de langage, et on en vient à un choix de plateforme, choix forcément très dépendant du contexte !

  

C’est cool si t’es tombé amoureux du Go, mais sache que de nombreux systèmes concurrentielles hautement performant (High Frequency Trading…) fonctionne en .Net (avec de vrai bout de C# dedans) et s’en porte plutôt bien. Malgré toute les insanités qu’on peut prêter au C# et à sa machine virtuelle (car des solutions ont été apportées par MS) :)

Gooom a écrit :



Mais quand tu veux faire du web/concurrency/system,  C# n’est pas fait pour ni la politique dominatrice de MS.





Tout à fait, c’est pour ça que j’ai cité F#. Un language fonctionnel est encore plus adapté au concurrentiel, et il a été dès le départ en open source (de fait, il n’a jamais été entre les mains de MS, c’est un produit de MS Research, filiale qui ne vend rien).