Le Mr plus haut ne nous a pas dit ce qu'il reprochait à Kotlin à part le fait que Big Brother n'en soit pas le géniteur.
Le Mr plus haut a un nom, pas besoin de rentrer dans ces jeux, et c’est plus facile de rechercher par la suite.
De 2, je ne reproche rien du tout à Kotlin. D’où tu imagines ça ? Tu penses que parce que j’aime Go, je suis Google fanboy ?
J’apprécie la Go Team, mais clairement, si ça dépendait que de Google, Go n’aurait jamais vu le jour. Le manager de Rob et Ken et Robert leur a permis d’expérimenter sur ce langage sans être affecté ailleurs. Si ça avait été un autre manager Google, sans l’expérience qu’avait ce manager vis à vis de Ken et Rob (ils bossaient ensemble aux Bell Labs), le projet Go aurait été mis aux oubliettes de Google.
Je m’auto héberge mes données sur nextcloud et évite au maximum Google et autre GAFAM.
Le monde n’est pas que noir et blanc, et le gris, c’est la majeur partie du monde.
Comme dit dans un autre message, je ne veux pas jouer au "mon langage est plus mieux que le tiens", mais je n’aime pas laisser des messages faux sans réponses.
On voit facilement ce que Go n'apporte pas au 22 Janvier 2020: Pas de traitement d'erreur digne de ce nom
Ok, c’est toujours rustique (haha), mais ça marche. Ils ont voulu améliorer avec le mot clé try (qui est, incroyablement proche du try rust dans ton post de comparaison Go VS Rust). Seulement, la communauté n’en voulait pas et a renvoyé la Go Team au tableau blanc pour réfléchir à une meilleure manière de faire voire trouver une solution communautaire
même même pas de gestion de modules avec un dépôt officiel
L’idée était de laisser la possibilité d’héberger là où on veut et de ne pas donner plus de travail à l’équipe Go. La gestion des dépendances n’est toujours pas complètement réglée, mais ça a bien avancé avec les modules, et grâce à ça, une sorte de centralisation de module existe maintenant avec le module proxy officiel dont une interface est disponible
même pas de généricité
Ian Lance Taylor et quelques autres s’y sont frotté. Ça doit être la 7ème ou 8ème implémentation des génériques qui a été testé. Mais les résultats n’ont jamais satisfait : soit c’était trop lent au runtime, soit trop lent à la compilation, soit la syntaxe était dégueu.
La communauté bloque beaucoup sur la syntaxe car on apprécie tous la simplicité de lire du Go. Rajouter une référence vers un type peut alourdir la lecture de code. Mais personnellement, la lib math avec des cast en float64 dans tous les sens, c’est pas un exemple de lisibilité si tu es en int. Du generics là dedans ferait le plus grand bien.
Pour les prochaines estimations, on perdrait entre 10 et 30% de temps de compilation sur des libs en génériques.
Un moyen de tester ces futurs générique en cours de dev: https://ccbrown.github.io/wasm-go-playground/experimental/generics/
(et pour le try)
L’idée, ce n’est pas d’inclure les 8 itérations des generics, mais d’avoir une implémentation correcte sur laquelle on peut compter pendant plusieurs années, et pas une API qui casse au bout de 3 mois.
Mis à part les goroutines, réimplémnentation un peu plus intégrée d'un concept de l'aube de l'informatique
Qui pourtant n’avait jamais vraiment été implémenté sur un langage récent connu.
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par 16aR . En réponse au journal Finalement c’est simple !. Évalué à 2.
Le Mr plus haut a un nom, pas besoin de rentrer dans ces jeux, et c’est plus facile de rechercher par la suite.
De 2, je ne reproche rien du tout à Kotlin. D’où tu imagines ça ? Tu penses que parce que j’aime Go, je suis Google fanboy ?
J’apprécie la Go Team, mais clairement, si ça dépendait que de Google, Go n’aurait jamais vu le jour. Le manager de Rob et Ken et Robert leur a permis d’expérimenter sur ce langage sans être affecté ailleurs. Si ça avait été un autre manager Google, sans l’expérience qu’avait ce manager vis à vis de Ken et Rob (ils bossaient ensemble aux Bell Labs), le projet Go aurait été mis aux oubliettes de Google.
Je m’auto héberge mes données sur nextcloud et évite au maximum Google et autre GAFAM.
Le monde n’est pas que noir et blanc, et le gris, c’est la majeur partie du monde.
Comme dit dans un autre message, je ne veux pas jouer au "mon langage est plus mieux que le tiens", mais je n’aime pas laisser des messages faux sans réponses.
Ok, c’est toujours rustique (haha), mais ça marche. Ils ont voulu améliorer avec le mot clé try (qui est, incroyablement proche du try rust dans ton post de comparaison Go VS Rust). Seulement, la communauté n’en voulait pas et a renvoyé la Go Team au tableau blanc pour réfléchir à une meilleure manière de faire voire trouver une solution communautaire
Oui, ça reste un langage impératif. On a quand même l’avantage de fonctions en tant que type de base et la syntaxe est plus agréable/lisible que sur une syntaxe C classique.
L’idée était de laisser la possibilité d’héberger là où on veut et de ne pas donner plus de travail à l’équipe Go. La gestion des dépendances n’est toujours pas complètement réglée, mais ça a bien avancé avec les modules, et grâce à ça, une sorte de centralisation de module existe maintenant avec le module proxy officiel dont une interface est disponible
Ian Lance Taylor et quelques autres s’y sont frotté. Ça doit être la 7ème ou 8ème implémentation des génériques qui a été testé. Mais les résultats n’ont jamais satisfait : soit c’était trop lent au runtime, soit trop lent à la compilation, soit la syntaxe était dégueu.
La communauté bloque beaucoup sur la syntaxe car on apprécie tous la simplicité de lire du Go. Rajouter une référence vers un type peut alourdir la lecture de code. Mais personnellement, la lib
mathavec des cast en float64 dans tous les sens, c’est pas un exemple de lisibilité si tu es enint. Du generics là dedans ferait le plus grand bien.Pour les prochaines estimations, on perdrait entre 10 et 30% de temps de compilation sur des libs en génériques.
Un moyen de tester ces futurs générique en cours de dev: https://ccbrown.github.io/wasm-go-playground/experimental/generics/
(et pour le try)
L’idée, ce n’est pas d’inclure les 8 itérations des generics, mais d’avoir une implémentation correcte sur laquelle on peut compter pendant plusieurs années, et pas une API qui casse au bout de 3 mois.
Qui pourtant n’avait jamais vraiment été implémenté sur un langage récent connu.