Microsoft prépare-t-il Windows Midori ?

WOW j'ai hâte de voir ça

moi aussi (vous êtes sur que l'on ai pas le 1 avril ^^) a voir..

C'est bien beau tout ça mais il restera toujours à programmer la couche entre le matériel et la machine virtuelle, non ?

En attendant, Midori c'est le nom d'un navigateur web Mozilla pour linux :
Midori
fast, lightweight graphical web browser

Midori is a lightweight web browser based on WebKit.
Its features include:
• Full integration with GTK+2.
• Fast rendering with WebKit.
• Tabs, windows and session management.
• Flexibly configurable Web Search.
• User scripts and user styles support.
• Straightforward bookmark management.
• Customizable and extensible interface.
• Support for extensions (written in C).
• Custom context menu actions.
Canonical ne propose pas de mise à jour pour Midori. Certaines mises à jour peuvent être fournies par la communauté Ubuntu.

Ah ouais! Super innovant, on en avait jamais entendu parler avant...

C'est pas ce que Sun voulait faire avec Java OS en 1996?

Toujours aussi en avance sur leur temps chez Microsoft.

Et ils l'ont fait?

Midori est un projet de navigateur Web (ultra-léger) pour XFCE.
Ils vont pas loins chercher des noms de code chez MS.

En même temps le nom du truc de Microsoft circule depuis début 2008, le navigateur Midori depuis mi-2008. Donc bon, hein. Voilà.

Et ça serait pas la première fois que deux programmes ont un nom similaire... iTunes, Tor, Edit, Vista, XP, Seven, Leopard, DirectX, Xbox...

Les Anti-Microsoft Débarquent Tention , Vivement midori, Une nouvelle approche des OS par microsoft?

On dirait que les pisse-vinaigre sont de sortie !

J'ai peine à croire que Microsoft rêve d'unité quand on vois le merdier qu'ils sont capables de sortir : Windows Mobile, Phone 7 Series, Pink (Turtle et Pure), Zune, Zune HD, Sync, ... chacun fonctionnant à sa sauce malgré un noyau unique : CE.

Alors bon, "Midori et le désir d'unification de Microsoft" j'y croirais quand ça sortira

@Storos: JavaOS a existé? Ben, oui (des versions de test du moins) - sauf que c'était tellement lent que personne n'en a voulu. Y'a peut-être un truc à creuser, là.

Encore que...

[sarcasme]Après tout, si tout le monde a des hexacore 4 GHz avec des cartes graphiques accélérées 350 Gflops, c'est pour faire tourner un navigateur Web dans une machine virtuelle à la même vitesse qu'un navigateur Web programmé en C++ compilé pour tourner sur un ARM 400 MHz...[/sarcasme]

La question que je me pose:

- puisque 'Crosoft a laissé tomber les Itanium,
- puisque 'Crosoft a laissé tomber les Alpha,
- puisque 'Crosoft n'a jamais touché au PowerPC (et donc au Cell),
- puisque 'Crosoft bidouille de l'ARM du bout des lèvres,
- puisque 'Crosoft laisse tomber le x86-32 pour tout concentrer sur le x86-64,

le nombre total de plateformes supportées par Windows Midori sera de 1.

L'intérêt principal d'un système en code source managé est d'être complètement détaché de la plateforme (voir Java, .Net) afin de pouvoir exécuter la même binaire sur n'importe quel processeur.

Quel intérêt s'il n'y a qu'une seule plateforme à supporter?

Oui, la question a été longue à venir. Allez, on va tenter une réponse...

Déjà, les performances, non - le premier qui me sort que .Net tourne aussi vite que si on compile son C++ en natif, il retourne voir quel éditeur de logiciel performant s'en sert. Y'a pas un seul jeu 3D en .Net, par exemple.

Bon, alors passons sur l'aspect sécurité (qui va main dans la main avec la stabilité). Là, c'est plus délicat.

La sensibilité principale d'un processeur x86 est qu'il n'y a pas de protection lorsque du code fonctionne sur la boucle 0 du proc' - c'est la boucle dans laquelle s'exécute le noyau du système d'exploitation - et, traditionnellement sous Windows jusqu'à l'arrivée de Vista, la sous-couche graphique (Vista et 7 font désormais tourner cette couche dans l'espace utilisateur).

Cette structure fait que, sur x86 du moins, moins on fait tourner de code dans la boucle 0, mieux on se porte. Mais ça va aussi plus moins viteuh (de l'ordre de 20% de perte).

En gros, il 'suffirait' de faire tourner un OS sans toucher à la boucle 0 pour qu'il ne plante plus - contre un coût moyen de 20% de performance brute. Ah oui mais, sorti de la boucle 0, y'a plus d'accès aux périphériques... Donc il faut un p'tit bout de machin qui tourne dans la boucle 0.

A l'origine, des p'tits gars ont pensé à un micronoyau (microkernel): ce machin ne servirait qu'à faire passer des messages entre les périphériques et l'espace traitement utilisateur - c'est par exemple le schéma de MINIX, et c'est ce à quoi NT 5 aspirait.

Avant de rigoler par rapport aux parts de marché de MINIX, 'faut savoir que c'est le seul OS basé sur un micronoyau que vous pouvez tester gratuitement. Et il est stable - genre, serveur Web qui se prend une DDoS dans la tronche sans rendre l'âme. Chez 'Crosoft ils ont pas encore ça, chez Linux ça passe ou pas, chez BSD c'est pas couvert par la garantie.

Oui mais un micronoyau, un vrai, ça demande de repenser toute l'architecture Windows! Et ce serait presque performant!

Repenser l'archi Windows, ça demande de laisser tomber un gros morceau de compatibilité. Y'a qu'à voir le patacaisse avec Vista avec la compatibilité Windows 2000/XP sp1 disparue (Vista est certifié compatible XP SP2 - toute appli certifiée XP sp2 tourne donc sur Vista).

En plus, faire un Windows efficace, ça fait que les gens vont pas vouloir acheter des PC avec des quadriprocesseurs, des cartes graphiques accélérées et 16 Go de RAM pour jouer au solitaire - les OEMs vont pas aimer.

Donc, il faut trouver autre chose. Actuellement, une bonne idée est la machine virtuelle.

Faire tourner une machine virtuelle de manière sécurisée demande de la faire tourner dans l'espace utilisateur, comme tout autre processus; oui mais, pour accéder au matériel, il faut donc demander au noyau (boucle 0) de le faire 'à sa place', de copier les données à transférer de la boucle 0 à la boucle utilisateur, et vice versa - c'est sûr, mais c'est TRES lent - de l'ordre de 90% de performance gâchées.

Donc, pour arranger cela, on a créé:
- d'abord des interfaces virtuelles pour un accès au matériel facilité pour les processus en espace utilisateur (ça va plus vite),
- puis des extensions processeur qui permettent de sauvegarder l'état de la boucle 0 et de le restaurer plus tard (ça reste stable quand ça va vite mais que l'invité fait des bêtises).

Résultat, si un OS est monté sur le schéma:
- un hyperviseur réduit et simplifié (plus c'est simple et moins y'a de bugs - le ratio complexité/bugs par ligne n'étant pas linéaire, un projet d'un million de lignes comprendra 100 fois mois de bugs qu'un projet de 10 millions de lignes), qui ferait office de micronoyau 'gonflé' offrant des interfaces de message standardisées par classe de périphérique,
- un (ou plusieurs) invité(s) avec accès direct (mais avec des interfaces neutres) au matériel,

T'as la stabilité d'un micronoyau, les avantages de la rétrocompatibilité, et des performances acceptables (par exemple, j'ai 24 images/sec en moyenne sous FurMark 1.8 natif, 17 images/sec en Furmark sous une VM) puisque le code exécuté par la MV n'a pas besoin d'être recompilé pour la plateforme...

Alors, si un hyperviseur faisant tourner des OS invités avec un bon gros accès matos et des proc' stabilisés est raisonnablement rapide, parfaitement compatible, et hyper stable d'une part, et qu'il n'y a pas 36 plateformes processeur à supporter d'autre part mais une seule (mettons une et demie, encore qu'émuler un ARM 400 sur un x86-64 à 3 GHz, ça marche très bien), à quoi ça sert de s'emmerder avec encore une pseudomachine virtuelle?

Si Midori est un hyperviseur capable de faire tourner un OS Win32/64 complet en invité, chouette - j'en veux!

Si Midori est juste le noyau de '.Net OS', par contre, ben zut - pas plus stable, pas plus sûr, plus lent et plus gras, désolé j'en veux pas.

Taper sur du 'Crosoft ne m'intéresse pas (enfin, pas plus que le péquin moyen); taper sur des logiciels foireux qu'on va nous mettre en travers de la gorge de force, beuêrk!

@Mitch Buchannon: wouach, t'as tout déchiré M'enfin j'ai tout lu intéressant (très).

c'est clair trop fort ce Mitch t'es programmer ou kwa? lol

@mitch
Si Midori est un hyperviseur, à mon avis c'est un peu près sur vu que comme tu dis c'est le seul moyen de gérer le legacy de façon efficace (intéressant tes chiffres pour FurMark d'ailleur). Il y a encore des progrès à faire comme la virtualisation du PCIe complète (je crois que ça viendra avec PCIe gen3) et tout ce qui est IO en général.

Une chose est sure, le ration historique 1:1 entre le hard et le système d'exploitation va tomber définitivement.

Pour ce qui est est des perfos du code managé .NET, il devrait être largement meilleur vu que tout tournera dans le même ring (donc plus de transitions couteuses user-space, kernel-space). Microsoft semble dire aussi que le bytecode sera directement converti en code machine à l'instale d'un soft, et non plus executé en JIT.
De toute façon un des vrais avantages de Midori devrait être le fait de pouvoir créer des milliers de thread pour une appli, sans que les perfos s'éffondrent ou que la mémoire explose, et ce grace à ce mécanisme de SIP (software isolated process).

Là ou ça peut être intéressant c'est que AMD et Intel risquent surement d'orienter leur CPU vers des architectures hybrides, c'est à dire: quelques cores complexes et x86 (OOO, très bonne prédiction de branchement) avec un cache important pour tout ce qui est code existant, et le reste serait des centaines de cores très simples (chaque fabriquant ayant potentiellement sa propre ISA) et avec peu de cache.

Donc à ce moment l'OS serait capable de gérer lui-même différent modèles de parallelisme, comme le paralllelisme de tâches ou de données (à la manière de CUDA ou OpenCL) voir d'autres modèles définissables par les développeurs via un driver qui implémenterait un scheduleur à partir de brique de base que l'OS lui fournirait + des instructions IL privilégiées. Ce qui lui permettrait directement de reprogrammer les modèles de parallèlisme fournis de base avec l'OS, (par exemple celui de CUDA). Après tout Intel a montré qu'il a réussi à le faire entièrement en software, donc pourquoi pas offrir ça au niveau de l'OS.

Pour ceux que ça intéresse:
http://channel9.msdn.com/shows/Goi [...] the-Years/
On y apprend notamment que la plupart des developpeurs de la CLR sont parti pour travailler sur Midori.

J'bosse pas avec un string rouge à Malibu - et j'suis pas plus programmeur que ça. Par contre, je bricole des PC depuis que ça existe (8088 à 4,77MHz et 512 Ko de RAM), et dans mes quêtes de performance, j'ai bidouillé plus d'un BIOS, patché plus d'un exécutable, et analysé plus de journaux de fonctionnement qu'un bon paquet de gens qui se targuent d'être "pro de l'informatique".

J'suis pas un pro; être un pro, c'est construire le Titanic. Etre un amateur, c'est faire l'arche de Noé. On sait lequel a coulé.

Ben écoute, parole de pro : tu t'y connais vachement bien. On voit d'ailleurs rarement des posts d'une telle qualité

+1 pour Midori le navigateur qui mérite le détour (mais il n'a rien à voir avec la fondation Mozilla, donc avec la famille Firefox puisqu'il utilise le moteur Webkit et non pas Gecko ) :

- Homepage > http://www.twotoasts.de/index.php? [...] mmary.html
- Page Wikipedia > http://fr.wikipedia.org/wiki/Midori_(navigateur)

Développé pour correspondre à la philosophie d'origine de l'environnement de bureau Xfce, il va tout aussi bien pour les autres et notamment LXDE (qui a repris à son compte le principe de légèreté laissé de côté depuis par Xfce), où il concurrence Chromium sans rougir !

En tout ça fait toujours plaisir de lire des posts de cette qualité il est clair
Je ne regrette pas d'etre inscrit sur ce site

@SeriousGilles: ton raisonnement se tient, et je n'en disconviens pas; par contre:

- s'il faut recompiler un soft à chaque install, je ne vois plus trop l'intérêt de livrer des binaires: autant livrer du code source direct. Amateurs du pingouin, vous pouvez rigoler. Je sais que compiler du bytecode n'a pas grand-chose à voir avec la compilation de langage type C (déjà, tu te simplifies le linker, le parser est aux abonnés absents, et t'as pas besoin de porter toutes les bibliothèques de la VM sur toute nouvelle plateforme), n'empêche que j'imagine mal de devoir passer 5 heures pour installer Mastodonte Office 2015... C'est déjà bien assez le waï en copie directe depuis un DVD.

Ou sinon, tu vas passer beaucoup de place pour stocker le bytecode et à côté le code machine généré au fur et à mesure de l'utilisation de la chose.

[sarcasme]Ceux qui rigolaient en pointant du doigt OpenOffice.org parce que un PARTIE de la suite est en Java, mangez-vous ça dans les babines: Mastodonte Office 2015/Midori sera en .Net! Bwaaaahahahahaaaaaa! *gasp* *sniff* *koff* [/sarcasme] Passons.

Pour les core hyper parallélisés, c'est sûr on y va à toute allure - on y est déjà chez AMD (les plateformes Dragon et Spider, ils nous bassinent les oreilles avec depuis 2007, c'est pas seulement pour les jolis stickers) et NVIDIA d'ailleurs, seulement CUDA etc. ne sont accessibles que via des interfaces proprio et dédiées; j'attends plus d'un truc du genre Gallium, par exemple - lequel fournit d'ailleurs briques de base, interfaces et scheduler, à un process ou à une VM. Pour le moment c'est encore expérimental, les pilotes Intel et AMD sont embryonnaires, mais le rasterizer logiciel est déjà plus performant que Mesa, il y a aussi un prototype de pilote générique XvMC et un OpenCL en cours de finalisation - c'est prometteur, ça marche déjà un peu.

De plus, le 'Cloud Computing' ayant dématérialisé les tâches et la virtualisation ayant dématérialisé la machine, on peut vraiment, maintenant, se demander à quoi vont servir les clients lourds. A ce rythme, on aura tous chez soi des tablettes tactiles (sans pomme pour moi, merci) avec un serveur qq part dans le garage. Star Trek power.

Là où je suis moins d'accord, c'est de l'utilité de virtualiser les bus de données: ce n'est pas nécessaire, et ce serait même dangereux, dans le sens où la gestion des IO est justement le rôle de l'hyperviseur, lequel se charge principalement que tous ces joyeux systèmes ne se marchassent pas sur les extensions digitales postérieures... Les orteils, quoi - suivez, un peu!

Par contre, et là je te suis davantage, donner la capacité aux invités d'indiquer à l'hyperviseur quelle charge ils s'attendent à exercer sur les bus de données (y'en a un qui sollicite un gros accès à la/aux CG, l'autre par contre préfère donner du boulot au sous-système disque, une troisième va mettre à mal la connexion Fiber Channel pour des sauvegardes, il faut aussi déterminer la bande passante minimale pour chaque invité etc.), ce serait effectivement fort utile - une sorte d'UPnP pour PCI Express, en gros.

En fait Microsoft a sorti (ou va) une version de NGEN (Parallel NGEN je crois que ça s'appelle) qui permet de paralleliser la generation des images natives (x86) d'un executable à partir des assemblies .NET (bytecode intermédiare). Donc d'un point de vue performances, si le futur nous réserve des CPUs massivement parallele, (pas trop de doutes la dessus) ça devrait pas prendre des plombes. Et ça pourrait être fait en parallele à la lecture de ton DVD (ou stream réseau plus probablement d'ici 5 ans).

Quant à ton idée de livrer du code source au lieu d'un bytecode, j'ai bien rigolé, merci . 1) Va expliquer à une boite qu'ils doivent fournir en clair tout le code source de leur appli (déjà qu'une des grosses critiques que font les gens à l'égard des langages managés comme Java ou C#, c'est la possibilité de décompiler le code). 2) Si tu as un soft de 10 millions de lignes en C#, il faut rajouter le temps de la compilation (qui est bien plus complexe que juste compiler du bytecode, comme tu le soulignes), et la tu pourras vraiment poireauter pendant l'install de ton soft.

Pour la virtualisation des IO, je penses que c'est juste une question de performances, mais après je ne m'y connais pas vraiment la dedans.

T'es sûr ? Pas un ? Même pas tous les jeux en XNA ?

@Mictateur: c'est une blague. J'espère vraiment que tu n'es pas sérieux.

Pour être plus clair (j'suis sûr qu'il y en a qui n'ont pas suivi), XNA est un environnement de programmation ultra simplifié, où on assemble des objets et des comportements pour faire un jeu.

Je ne suis pas sûr, par contre, que tu puisses intégrer une intelligence artificielle dont chaque instance est capable de communiquer avec une autre pour modifier la stratégie du groupe. Je ne suis pas certain, non plus, que le moteur physique utilisé puisse représenter, prenons un exemple, la déchirure d'un bout de tissu ou la dynamique d'adhérence de pneus sur l'asphalte mouillé à une vitesse de 250 Km/h lorsque un moteur avec une démultiplication de 1.475 applique une torsion de 300 Nm à son axe de transmission.

En gros, un FPS, un simulateur automobile...

@Serious Gilles: pour être plus précis, entre chaque périph' de ton PC, il y a un bus de données. Depuis quelques années déjà, la plupart de ces bus sont composés de plusieurs connexions de type 'série' (pas plus de 8 ou 16 brins de large), tournant chacune à très grande vitesse, et capables d'être mises en parallèle, activées et désactivées, plus ou moins à volonté.

Le cas du PCI Express est, en ce sens, très intéressant: il reprend le protocole de données du bus PCI (un bus parallèle, d'une largeur de 32-bit, cadencé à 33 MHz pour la version 'classique') mais l'applique en fait à plusieurs connexions: en essence, un bus PCI Express v1 x4 représente le même débit que 4 bus PCI 'classiques', mais chaque bus PCI classique 'virtuel' de la connexion PCI-E est indépendant des autres.

Dans l'absolu, on peut (en téhorie) connecter une carte graphique PCI Express x16 sur un bus PCI Express x1: ça fonctionnera comme en x16, mais avec un seizième du débit maximal. C'est le rôle du (des) contrôleur(s) de bus de déterminer ce qui est connecté, et où, avec combien de lignes.

Les révisions suivantes du PCI Express ont augmenté le débit de la chose, mais ont surtout augmenté la souplesse de la chose: la capacité de désactiver des lignes PCI Express si le niveau ACPI descend, ou sur demande de l'OS, par exemple, en est une bonne illustration.

Bon. Par contre, il reste un problème: la plupart des contrôleurs de bus ne peuvent pas gérer simultanément tous leurs connecteurs physiques: leur logique intégrée ne leur permet que d'en gérer une partie.

Pour le moment, c'est via des réglages du BIOS (profils ACPI, attributions manuelles, etc.) que cette répartition est déterminée: il est, par exemple, notable que certains fabricants de cartes mères ont créé des solutions multi-GPU en filant un PCI Express x8 à la première, x8 à la seconde, ces deux-là en passant par le bus du chipset, et une x4 à la 3e, en passant par un chip secondaire. Par contre, la même carte mère avec une seule GPU peut balancer du x16 à ladite GPU.

Bien entendu, le panard total serait que tous les contrôleurs puissent gérer toutes leurs connexions simultanément. Il y en a qui peuvent, mais:
- c'est cher
- 90% du temps, ces connexions summplémentaires sont gâchées.

La solution économique est donc de permettre à l'OS de gérer quelles connexions sont actives, et sur quoi elles sont concentrées. C'est probablement ce qu'incluera la norme PCI-E 3: la capacité pour l'OS de réaffecter dynamiquement (c-à-d sans rebooter) le contrôleur de bus à telle ou telle ligne matérielle.

Il est par exemple notoire que lorsqu'on se tape un bon gros frag', on évite de sauvegarder toute sa grappe RAID via Fiber Channel à 3 Go/sec; donc, sur les 16 + 8 connexions PCI Express gérées par le chipset et le processeur, on peut en laisser 8 et 8 sur les deux GPU, deux sur la carte son EAX 5, une sur le contrôleur USB, deux sur la carte réseau Gigabit Ethernet accélérée à basse latence, une sur le lecteur/graveur BluRay et deux sur la grappe RAID; lorsque on voudra faire la sauvegarde du système, on redirigera 4 lignes sur le contrôleur Fiber Channel et 4 lignes sur le contrôleur RAID; on gardera une ligne PCI-E sur la GPU active pour le bureau, et basta.

Bon.

Si on revient au cas d'un hyperviseur, celui-ci ne pourra qu'analyser le comportement des VM et adapter les lignes contrôlées qu'après coup. Une des VM pourrait, par exemple, être en veille, ou faire du number crunching avec nécessité d'accéder seulement au stockage de masse, et à basse vitesse encore, pendant qu'une autre aura besoin de la carte FC plein pot pendant 5 heures. Si les VM pouvaient dire à l'hyperviseur, "j'ai besoin d'accéder au RAID avec un max de vitesse, mais pas à la CG", ou "j'ai pas besoin de beaucoup d'I/O pour le moment", l'hyperviseur pourra être plus efficace sur la répartition des ressources.

On passerait d'un multicanal adaptatif à un multicanal collaboratif. Ca simplifierait d'une part le scheduler de l'hyperviseur, et ça serait plus efficace d'autre part.

c'est moi ou personne n'a tiqué que cela va être du closed-source encore plus renforcé au profit de Microsoft ?
- "le fait d’imposer le runtime Silverlight" déjà pour le 7 Phone
- "le langage de programmation F#" livré le mois prochain (juste le temps de commencer à développer dessus pour la sortie de Midori)

hé ho, au lieu de se battre à savoir comment ça va marcher, regardez plutôt avec QUOI cela va marcher ! après DirectX (devenu un standard même si le 10 n'est que peu utilisé, et le 11... n'en parlons pas), 2 autres futur "standard Microsoft".

@teso7848: ça nous changera pas de maintenant, puisque 'Crosoft distribue uniquement des binaires, et la doc qui va avec est au mieux incomplète (quand elle n'est pas fausse) et au pire volontairement réduite.

Y'a eu du mieux sur les protocoles et langages ouverts que MS a tenté de pervertir (HTTP, TCP/IP, XML, ECMAscript, LDAP) et quelques procès bien sentis les ont forcés à jouer franc jeu sur d'autres (SVG, CIFS, Office OpenXML), mais c'est sûr qu'une machine virtuelle de plus ça la fout mal.

Soyons optimistes, ils publient les spécifications de conformité de Silverlight au fur et à mesure des versions, si Moonlight est une quelconque indication.

Mais Sun avait fait pareil avec Java. Mieux même, Java 6 est entièrement sous GPLv3.

Quant à Silverlight, par rapport à SVG+HTML5+Javascript, je vois pas trop l'intérêt, j'avoue: les dernières démonstrations (Firefox 3.7 et IE 9) avec accélération matérielle et compilation JIT donnent des résultats assez bluffants au niveau de la fluidité, et si Quake 2 peut tourner en Javascript+HTML5+SVG dans Chrome (lequel n'a pas - encore - l'accélération matérielle), franchement, quel besoin...?

Silverlight, déjà, est multi-plateforme, même si Linux and co y'a un peu de retard. C'est basé sur des standards (CLR, toussa), sisisi, et y'a une bonne partie qui est ouverte.
Ensuite, s'ils forcent Silverlight, c'est parce qu'ils ont pas encore les outils pour les applis en code natif. Sinon, évidemment qu'ils te fileraient le tout à la sortie, ça permettrait d'entrée de jeu d'avoir des dizaines de milliers d'applis compatibles. Je te parie qu'à la R2 de WP7, on ait magiquement droit aux applis en C/C++.


Sinon, le F# date de 2002... Ce n'est que maintenant que le langage passe de blagounette de Microsoft Research à langage .NET officiel supporté.

C'est plutôt Sun et son Fortress qui passe pour une blagounette à côté de F#.
"Although a preliminary interpreted implementation of the language was produced, the DARPA contract was not renewed in November 2006,[2] leading to uncertainty about the language's future"
Dommage ça avait l'air vraiment prometteur. Enfin... sur la JVM il reste Scala développé par l'EPFL.

Fortress, 2 questions:

http://stackoverflow.com/questions/tagged/fortress

F#, 874 questions:

http://stackoverflow.com/questions/tagged/f%23

Scala, 1025 questions:

http://stackoverflow.com/questions/tagged/scala

Le F# c'est juste très très très différent, et moi qui suis de base un programmeur assembleur/C, bien que je touche largement ma bille en Java et C#, j'ai franchement du mal à me coller au F#.
Et même si je suis pas foutu de m'en servir de façon utile et que j'ai pas le bon raisonnement pour l'exploiter à fond, je vois clairement la puissance du machin et je suis parfaitement confiant sur ses capacités. C'est pas pour autant ce qui va lui offrir le succès, mais si ils pondent un OS autour de ça, ça risque fortement.

En attendant je m'y mets à fond pour essayer d'arriver à faire quelque chose avec, parce que ça fait vraiment envie

C'est toujours beau la théorie, mais qu'en sera t-l en pratique ?