Sinon, concernant ton explication que Windows n'a pas d'appel à fork : c'est vrai, il n'y a pas de fork POSIX (quoique, c'est plus tout à fait vrai depuis un petit moment, vu qu'il existe une implémentation d'une partie de l'API POSIX en Windows « natif » pour Win10 depuis quelques mois déjà). Mais tu penses bien qu'ils ont un moyen de dupliquer l'espace mémoire d'un processus s'il le faut. :-) C'est juste que l'API est plus complexe. Voir ici par exemple.
Bof ... ça sent plus le troll qu'autre chose. Les solutions qui sont de passer par cygwin, l'api posix de windows me semblent tout sauf simple. Déjà passer par cygwin pour python nécessite de tout installer dans cet environnement, qui est indépendant du reste de windows. Cela fait une couche logicielle importante. En ce qui concerne les couches posix, il semblerait que ce soit avec interix ou wsl c'est tout sauf simple à faire cohabiter. Donc perso, je pense qu'il vaut mieux coder cross-plateform dès le début que de passer par des mécanismes qui vont te demander un investissement important à chaque fois qu'ils vont les faire évoluer ...
Après concernant Process VS Threads, tu es bien plus pertinent que moi pour pouvoir en juger. Mais je trouve que les outils comme MesgPack, ZMQ, et ZeroRPC, permettent d'étendre la mise en œuvre des process. Par exemple chez nous on envisage d'avoir des services qui tournent sur des PC dédiés et que l'on appelle dans python sur d'autres PC grâce à ZeroRPC. Cela n'est pas si compliqué à faire lorsque l'on s'est mis dans les contraintes du multi-process, c'est bien plus difficile si l'on part du multi-thread (enfin je pense, on ne l'a pas encore fait ...).
Si je suis d'accord avec toi sur l'aspect coût en mémoire, en fait dans mon cas d'utilisation, cela ne va pas changer grand chose de mettre en mémoire les 8 interpréteurs, sur ma machine. C'est sur que s'il faut dupliquer les flux de données important pour émuler la mémoire partagé, cela perd vraiment de l'intérêt. Mais généralement quand tu en es là, tu peux tout à fait partir sur un module cython et relacher le GIL, cela me semble bien moins compliqué que de passer toute sa base de code de python vers Go.
C'est plutôt un acte politique, ils ont développé un langage haut niveau performant et bien plus simple à maîtriser que le C++, ils veulent donc le promouvoir, ce qui est bien. C'est juste que je trouve la tentative de justification avec python, un peu limite. C'est bien de respecter le travail de ses développeurs et de leur faire confiance, pour moi c'est une raison suffisante.
[^] # Re: L'annonce
Posté par freejeff . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 2.
Bof ... ça sent plus le troll qu'autre chose. Les solutions qui sont de passer par cygwin, l'api posix de windows me semblent tout sauf simple. Déjà passer par cygwin pour python nécessite de tout installer dans cet environnement, qui est indépendant du reste de windows. Cela fait une couche logicielle importante. En ce qui concerne les couches posix, il semblerait que ce soit avec interix ou wsl c'est tout sauf simple à faire cohabiter. Donc perso, je pense qu'il vaut mieux coder cross-plateform dès le début que de passer par des mécanismes qui vont te demander un investissement important à chaque fois qu'ils vont les faire évoluer ...
Après concernant Process VS Threads, tu es bien plus pertinent que moi pour pouvoir en juger. Mais je trouve que les outils comme MesgPack, ZMQ, et ZeroRPC, permettent d'étendre la mise en œuvre des process. Par exemple chez nous on envisage d'avoir des services qui tournent sur des PC dédiés et que l'on appelle dans python sur d'autres PC grâce à ZeroRPC. Cela n'est pas si compliqué à faire lorsque l'on s'est mis dans les contraintes du multi-process, c'est bien plus difficile si l'on part du multi-thread (enfin je pense, on ne l'a pas encore fait ...).
Si je suis d'accord avec toi sur l'aspect coût en mémoire, en fait dans mon cas d'utilisation, cela ne va pas changer grand chose de mettre en mémoire les 8 interpréteurs, sur ma machine. C'est sur que s'il faut dupliquer les flux de données important pour émuler la mémoire partagé, cela perd vraiment de l'intérêt. Mais généralement quand tu en es là, tu peux tout à fait partir sur un module cython et relacher le GIL, cela me semble bien moins compliqué que de passer toute sa base de code de python vers Go.
C'est plutôt un acte politique, ils ont développé un langage haut niveau performant et bien plus simple à maîtriser que le C++, ils veulent donc le promouvoir, ce qui est bien. C'est juste que je trouve la tentative de justification avec python, un peu limite. C'est bien de respecter le travail de ses développeurs et de leur faire confiance, pour moi c'est une raison suffisante.