Posté par gasche .
En réponse à la dépêche JRuby 1.7.0.
Évalué à 5.
Dernière modification le 26 octobre 2012 à 17:04.
Dans la vraie vie ça ne marche pas toujours aussi bien : la JVM a été pensée pour Java et la viser depuis un autre langage peut poser problème si ta sémantique est vraiment différente. Typiquement tu ne vas pas pouvoir réutiliser le modèle objet (mais invoke_dynamic est censé aider pour ça), ou alors ton langage utilise beaucoup les appels terminaux qui ne sont pas optimisés en Java pour des raisons moisies, ou tu utilises des exceptions qui se traînent le ventre par terre sur la JVM ou sur la machine virtuelle .NET.
Même pour les langages dynamiques implémentés avec les pieds comme Python, PHP ou Ruby, les gens pensaient avoir de gros gains en utilisant un runtime "state of the art" comme Java ou un JIT existant comme LLVM, et en fait c'est loin d'être aussi simple, la perte de contrôle sur la représentation des données ou certains points d'optimisation fait que c'est finalement assez dur de faire franchement beaucoup mieux en peu d'efforts; et même quand tu y arrives, tu découvres que les utilisateurs ont codé les bouts performance-critiques en C en passant par une FFI toute moche reposant sur des détails internes de l'implémentation précédente, et t'es mort. C'est pour ça que les projets style Rubinius, JRuby, Pypy et compagnie ont la vie dure.
[^] # Re: Utilité ?
Posté par gasche . En réponse à la dépêche JRuby 1.7.0. Évalué à 5. Dernière modification le 26 octobre 2012 à 17:04.
Dans la vraie vie ça ne marche pas toujours aussi bien : la JVM a été pensée pour Java et la viser depuis un autre langage peut poser problème si ta sémantique est vraiment différente. Typiquement tu ne vas pas pouvoir réutiliser le modèle objet (mais invoke_dynamic est censé aider pour ça), ou alors ton langage utilise beaucoup les appels terminaux qui ne sont pas optimisés en Java pour des raisons moisies, ou tu utilises des exceptions qui se traînent le ventre par terre sur la JVM ou sur la machine virtuelle .NET.
Même pour les langages dynamiques implémentés avec les pieds comme Python, PHP ou Ruby, les gens pensaient avoir de gros gains en utilisant un runtime "state of the art" comme Java ou un JIT existant comme LLVM, et en fait c'est loin d'être aussi simple, la perte de contrôle sur la représentation des données ou certains points d'optimisation fait que c'est finalement assez dur de faire franchement beaucoup mieux en peu d'efforts; et même quand tu y arrives, tu découvres que les utilisateurs ont codé les bouts performance-critiques en C en passant par une FFI toute moche reposant sur des détails internes de l'implémentation précédente, et t'es mort. C'est pour ça que les projets style Rubinius, JRuby, Pypy et compagnie ont la vie dure.