L’interfaçage avec le C est absolument trivial : C.printf(C.CString("Hello, world !"))
Idem, on dirait qu'un ingé de chez google était jaloux devant les specs de scala et a voulu faire le sien en moins beau et beaucoup plus verbeux
Encore une fois, tu oublies l’élément « simplicité » du cahier des charges. Scala c’est beau, mais il faut avoir fait des études assez poussées pour comprendre ce que fait le compilateur derrière ton dos (chose qu’on explicitement voulu éviter les devs de Go).
Plus prosaïquement (la raison pour laquelle je ne l’utilise pas), tu te manges aussi la complexité de l’écosystème Java, avec Scala : un runtime pas des plus légers/intégré/simple (Go, il te pond un exécutable lié statiquement, un scp et c’est déployé), un environnement de dev bien lourd (maven ? eclipse ? non merci).
et les perfs c'est pas ça apparemment…
Ça dépend tu compares avec quoi.
La plupart des projets que je fais en Go aujourd’hui, je les aurai fait en Python hier. C’est un gain de performances vraiment appréciable.
Bon, on reprend, vu que j'ai pas été assez clair, apparemment :
Expressivité : Python > Go > C
Performances : C > Go > Python
C’est un compromis entre les deux. Encore une fois, le but c’est d’être presque aussi efficace que le C (pas aussi efficace), et presque aussi expressif que le python (pas aussi expressif).
Tu cherches rarement les performances pures. Tu cherches toujours un compromis performance/expressivité. L’intérêt de Go aujourd’hui, c’est son placement sur l’axe qui le rend intéressant.
Un langage comme Scheme (et ses multiples implémentations) est un concurrent sérieux.
Tu compares un langage impératif et un langage fonctionnel. Je ne veux pas rentrer dans le troll fonctionnel/impératif, mais pour faire court, force est de constater que tout le monde ne se retrouve pas forcément dans ce style.
(tout (le (monde (n'est (pas (fan)))))))
Personnellement c'est un langage que je trouve séduisant, mais son apprentissage vaut-il vraiment le coup ?
C’est l’avantage de Go : tu connais le C, tu connais Go. Son apprentissage est quasi-immédiat pour un dev C (Go, c’est du C avec un peu de sucre syntaxique (:=, interfaces, go, defer) et un GC).
Alors, quel est l'intérêt profond de Go ?
Go, fondamentalement, est à mi-chemin entre Python et C.
- Si le cahier des charges de ton projet te dirige vers le C pour des contraintes de « légèreté » (en terme d’infrastructure de runtime nécessaire, d’utilisation mémoire, que sais-je), alors Go pourrait être un bon candidat : proche du C sur ces points, il a l’avantage d’une meilleure expressivité.
- Si le cahier des charges de ton projet te dirige vers un langage interprété pour des contraintes de rapidité de développement, alors Go pourrait être un bon candidat : presque aussi expressif que Python, il est généralement bien plus performant.
Bref, l’intérêt profond de Go, c’est d’être « presque » aussi performant que le C en étant « presque » aussi expressif que Python.
D’un autre côté, étant à mi-chemin, tu perds aussi un peu des bons côtés des deux : côté C, le GC pourrait être un point bloquant ; côté Python, outre l’écosystème bien plus réduit, la méta-programmation est bien plus pénible en Go, et le typage statique limite parfois l’expressivité comparativement à ce qu’on pourrait retrouver dans un langage à typage dynamique (je pense par exemple aux collections, dont la gestion peut être parfois frustrante, ou à l’impossibilité d’un équivalent du type tuple en Python)
Ça te demande rien du tout, si ça tombe dans le domaine public Wikimedia se fera une joie de te fournir l’infrastructure (oui, je sais, il la paient cette infrastructure, mais il y a peu de chance qu’ils doivent augmenter leurs capacités pour un millier de bouquins).
A ma connaissance, c'est exactement l'inverse: déployer une application sur Windows est facile, il suffit de faire un installeur et il y a pas mal d'outil pour en faire des biens. Il est aussi assez facile d'embarquer toutes les libs dont tu as besoin.
C’est pas du déploiement ça, le déploiement c’est « je veux mettre mon soft sur 200 machines ». Tu vas faire clic-clic 200 fois, avec ton installeur ?
quel format d'empaquetage utilisé ?
comment m'assurer que toutes les libs dont j'ai besoin sont présentes dans la version où j'en ai besoin, pour le 86 distribitions Linux et 23 versions de chacune de ces distributions
J’ose espérer que tu n’as pas installé 86 distributions dans 23 versions différentes sur ton parc de machines. Si c’est le cas, le déploiement d’une application est, je le crains, le dernier de tes soucis.
pour sauvegarder les données de l'utilisateur, il faut bidouiller pour créer un répertoire dans le HOME de l'utilisateur mais tu es obligé de développer vachement de code "à la con" pour gérer plein de cas particuliers.
Pareil, dans un contexte où on parle de « déploiement », ton HOME c’est un NFS/Samba que tu peux gérer de manière centralisée pour tous les utilisateurs.
Et maintenant, quid de Mac OS ? Je me pose la même question, facilité de déploiement…
Pareil que Linux, grosso-modo. Les logiciels sont distribués en .pkg, qui est juste une grosse archive qui contient binaire, lib partagées et données.
Mais ça signifie aussi que les croisades ne sont pas incompatibles avec le christianisme en général (sinon ce serait incompatible avec le catholicisme romain en particulier).
Vouloir pouvoir débugger rc.sysinit ne signifie pas forcément avoir un bug dans rc.sysinit, mais ça peut vouloir dire que c’est le meilleur endroit pour ajouter un trace de debug (cat /proc/modules > /tmp/log) quand tu as un problème bizarre
Et oui, ça m’est arrivé il y a pas plus tard qu’un mois (pas le bug dans init, mais le fait d’avoir à ajouter des traces de debug très tôt dans la phase de boot qui est heureusement en shell)
C’est cat, less, gedit. Bref, des commandes que toute personne curieuse connaît.
juste un format qui change pour être plus structuré
Du coup, il faut :
- savoir que c’est un format spécial
- connaître les logiciels nécessaires pour pouvoir le lire
Aujourd’hui, tu connais ls, cd, et cat, tu peux découvrir 90% de ton système. Avec une telle logique (c’est pas grave, suffit d’écrire un logiciel qui parse le format structuré), ce n’est plus le cas.
Je comprend ton envie de bidouiller
Ce n’est pas mon envie de bidouiller. C’est l’envie de bidouiller du moi d’il y a dix ans. Et celle d’éventuels futurs curieux qui seront demain dans le même état d’esprit que j’étais il y a dix ans.
(mais c’est vrai qu’il faut avoir un sacré grain pour avoir envie de développer en Java sous Eclipse quand on peut développer en Objective-C avec Xcode ou vim…)
Ha mais attends, comment je sort les warnings et erreurs (mais pas debug, info) de apache, postfix, système, etc sur une plage de temps facilement ? Ben je peux pas.
man rsyslog.conf
Personne ne nie qu’un standard soit une bonne idée. Simplement, il existe déjà (c’est syslog), et vouloir utiliser du XML pour des logs, c’est, pour le dire poliment, pas particulièrement attirant.
Lapincompris le rapport.
« Écrivez des programmes qui traitent des flux de texte car c'est l'interface universelle »
Universelle, dans le sens : je peux utiliser la puissance d’outils comme sed/awk/grep/perl et des centaines d’autres, testés, éprouvés depuis des dizaines d’années, enseignés dans les plus mauvaises écoles d’administration système, installés sur virtuellement tous les systèmes, et qui ne me feront jamais faux bond, en les combinant d’une manière à laquelle personne d’autre n’a pensé parce que tout le monde s’en fout tellement mon problème est spécifique. Si tu me dis que je dois écrire un programme en Java avec un parser SAX pour résoudre mon problème spécifique, je te ris au nez (encore une fois, c’est la version polie).
[^] # Re: Intérêt
Posté par Moonz . En réponse à la dépêche Sortie d'une première version stable de Go. Évalué à 7.
L’interfaçage avec le C est absolument trivial :
C.printf(C.CString("Hello, world !"))Encore une fois, tu oublies l’élément « simplicité » du cahier des charges. Scala c’est beau, mais il faut avoir fait des études assez poussées pour comprendre ce que fait le compilateur derrière ton dos (chose qu’on explicitement voulu éviter les devs de Go).
Plus prosaïquement (la raison pour laquelle je ne l’utilise pas), tu te manges aussi la complexité de l’écosystème Java, avec Scala : un runtime pas des plus légers/intégré/simple (Go, il te pond un exécutable lié statiquement, un scp et c’est déployé), un environnement de dev bien lourd (maven ? eclipse ? non merci).
Ça dépend tu compares avec quoi.
La plupart des projets que je fais en Go aujourd’hui, je les aurai fait en Python hier. C’est un gain de performances vraiment appréciable.
[^] # Re: Intérêt
Posté par Moonz . En réponse à la dépêche Sortie d'une première version stable de Go. Évalué à 5.
Bon, on reprend, vu que j'ai pas été assez clair, apparemment :
Expressivité : Python > Go > C
Performances : C > Go > Python
C’est un compromis entre les deux. Encore une fois, le but c’est d’être presque aussi efficace que le C (pas aussi efficace), et presque aussi expressif que le python (pas aussi expressif).
Tu cherches rarement les performances pures. Tu cherches toujours un compromis performance/expressivité. L’intérêt de Go aujourd’hui, c’est son placement sur l’axe qui le rend intéressant.
[^] # Re: Intérêt
Posté par Moonz . En réponse à la dépêche Sortie d'une première version stable de Go. Évalué à 4.
C’est toujours plus rapide que Python.
[^] # Re: Intérêt
Posté par Moonz . En réponse à la dépêche Sortie d'une première version stable de Go. Évalué à 9.
Tu compares un langage impératif et un langage fonctionnel. Je ne veux pas rentrer dans le troll fonctionnel/impératif, mais pour faire court, force est de constater que tout le monde ne se retrouve pas forcément dans ce style.
(tout (le (monde (n'est (pas (fan)))))))
C’est l’avantage de Go : tu connais le C, tu connais Go. Son apprentissage est quasi-immédiat pour un dev C (Go, c’est du C avec un peu de sucre syntaxique (:=, interfaces, go, defer) et un GC).
Go, fondamentalement, est à mi-chemin entre Python et C.
- Si le cahier des charges de ton projet te dirige vers le C pour des contraintes de « légèreté » (en terme d’infrastructure de runtime nécessaire, d’utilisation mémoire, que sais-je), alors Go pourrait être un bon candidat : proche du C sur ces points, il a l’avantage d’une meilleure expressivité.
- Si le cahier des charges de ton projet te dirige vers un langage interprété pour des contraintes de rapidité de développement, alors Go pourrait être un bon candidat : presque aussi expressif que Python, il est généralement bien plus performant.
Bref, l’intérêt profond de Go, c’est d’être « presque » aussi performant que le C en étant « presque » aussi expressif que Python.
D’un autre côté, étant à mi-chemin, tu perds aussi un peu des bons côtés des deux : côté C, le GC pourrait être un point bloquant ; côté Python, outre l’écosystème bien plus réduit, la méta-programmation est bien plus pénible en Go, et le typage statique limite parfois l’expressivité comparativement à ce qu’on pourrait retrouver dans un langage à typage dynamique (je pense par exemple aux collections, dont la gestion peut être parfois frustrante, ou à l’impossibilité d’un équivalent du type tuple en Python)
[^] # Re: Pour les juristes
Posté par Moonz . En réponse au journal Suppression des droits d'auteurs. Évalué à 3.
Ça te demande rien du tout, si ça tombe dans le domaine public Wikimedia se fera une joie de te fournir l’infrastructure (oui, je sais, il la paient cette infrastructure, mais il y a peu de chance qu’ils doivent augmenter leurs capacités pour un millier de bouquins).
[^] # Re: procrastination mon amour
Posté par Moonz . En réponse au journal Auto-pub: bctl. Évalué à 5.
Damned, je suis démasqué.
Mais bon, savoir que ce n’est pas un claquage du poil de la main, c’est rassurant. C’est que ça pourrait être dangereux ce truc.
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par Moonz . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 4.
C’est pas du déploiement ça, le déploiement c’est « je veux mettre mon soft sur 200 machines ». Tu vas faire clic-clic 200 fois, avec ton installeur ?
J’ose espérer que tu n’as pas installé 86 distributions dans 23 versions différentes sur ton parc de machines. Si c’est le cas, le déploiement d’une application est, je le crains, le dernier de tes soucis.
Pareil, dans un contexte où on parle de « déploiement », ton HOME c’est un NFS/Samba que tu peux gérer de manière centralisée pour tous les utilisateurs.
Pareil que Linux, grosso-modo. Les logiciels sont distribués en .pkg, qui est juste une grosse archive qui contient binaire, lib partagées et données.
[^] # Re: Et bien…
Posté par Moonz . En réponse au journal Kernel en 32 bits ou en 64 bits (un journal bookmark). Évalué à 2.
https://bugs.freedesktop.org/show_bug.cgi?id=44466
[^] # Re: Quel avenir?
Posté par Moonz . En réponse au journal Go 1. Évalué à 3.
Même choix que Ruby, Lua, Python, CoffeeScript. À ton avis, pourquoi tous ces langages ont fait ce choix ?
Ça permet de clarifier grandement
char *foo[3](tableau de 3 char* ou pointeur sur un tableau de 3 char ?).[^] # Re: Et bien…
Posté par Moonz . En réponse au journal Kernel en 32 bits ou en 64 bits (un journal bookmark). Évalué à 5.
Wine + D3D + 64bits ne font pas bon ménage en ce moment (au hasard)
[^] # Re:Pitié
Posté par Moonz . En réponse au journal Mélenchon à 14% d'intentions de vote.... Évalué à 2.
Mais ça signifie aussi que les croisades ne sont pas incompatibles avec le christianisme en général (sinon ce serait incompatible avec le catholicisme romain en particulier).
[^] # Re: Trop similaires
Posté par Moonz . En réponse au journal Dotsies : remplacer l'alphabet !. Évalué à 3.
Perso noscript me bloquait les fonts externes.
[^] # Re: Trop similaires
Posté par Moonz . En réponse au journal Dotsies : remplacer l'alphabet !. Évalué à 5.
Et purtant, tu es capble de lire ce mesage.
[^] # Re:Sécuritédes backends
Posté par Moonz . En réponse à la dépêche Le Weboob nouveau est arrivé. Évalué à 2.
chmod 600 .config/weboob ça a quoi de moins bien qu’un keyring ?
[^] # Re: Sécurité des backends
Posté par Moonz . En réponse à la dépêche Le Weboob nouveau est arrivé. Évalué à 2.
C’est du Python. Tu ajoutes
et tu peux voir toutes les requêtes HTTP faites par Weboob, et s’il se connecte à hack.weboob.com, tu peux te poser des questions.
J’ai pas testé, mais tu devrais pouvoir faire ça aussi :
En jouant sur PYTHONPATH tu devrais même pouvoir faire ton propre socket.py qui fasse ça plus proprement.
Sinon, tu as aussi d’autres solutions du genre https://github.com/sloonz/utils/blob/master/bin/tcproxy + tsocks (
tcproxy 12345, puis tu configure tsocks pour passer en SOCKS 4 sur le port 12345)[^] # Re: Moui, moui...
Posté par Moonz . En réponse à la dépêche Projet numérique du Front de Gauche. Évalué à 3.
L’impôt sur le revenu est progressif depuis 1914 (d’après Wikipédia)
[^] # Re: Moui, moui...
Posté par Moonz . En réponse à la dépêche Projet numérique du Front de Gauche. Évalué à 2.
Depuis quand Sarkozy est-il devenu un exemple à suivre ?
[^] # Re: But
Posté par Moonz . En réponse à la dépêche Projet Lumberjack. Évalué à 4.
[^] # Re: But
Posté par Moonz . En réponse à la dépêche Projet Lumberjack. Évalué à 5.
Vouloir pouvoir débugger rc.sysinit ne signifie pas forcément avoir un bug dans rc.sysinit, mais ça peut vouloir dire que c’est le meilleur endroit pour ajouter un trace de debug (cat /proc/modules > /tmp/log) quand tu as un problème bizarre
Et oui, ça m’est arrivé il y a pas plus tard qu’un mois (pas le bug dans init, mais le fait d’avoir à ajouter des traces de debug très tôt dans la phase de boot qui est heureusement en shell)
[^] # Re: But
Posté par Moonz . En réponse à la dépêche Projet Lumberjack. Évalué à 4.
C’est cat, less, gedit. Bref, des commandes que toute personne curieuse connaît.
Du coup, il faut :
- savoir que c’est un format spécial
- connaître les logiciels nécessaires pour pouvoir le lire
Aujourd’hui, tu connais ls, cd, et cat, tu peux découvrir 90% de ton système. Avec une telle logique (c’est pas grave, suffit d’écrire un logiciel qui parse le format structuré), ce n’est plus le cas.
Ce n’est pas mon envie de bidouiller. C’est l’envie de bidouiller du moi d’il y a dix ans. Et celle d’éventuels futurs curieux qui seront demain dans le même état d’esprit que j’étais il y a dix ans.
[^] # Re: C'est pas pour toi
Posté par Moonz . En réponse au journal Chronique d'un flop annoncé. Évalué à 1. Dernière modification le 08 mars 2012 à 12:19.
Faux : http://sourceforge.net/mailarchive/forum.php?thread_name=4C88E7DB.20705%40puder.org&forum_name=xmlvm-users
(mais c’est vrai qu’il faut avoir un sacré grain pour avoir envie de développer en Java sous Eclipse quand on peut développer en Objective-C avec Xcode ou vim…)
[^] # Re: But
Posté par Moonz . En réponse à la dépêche Projet Lumberjack. Évalué à 9.
Effectivement, si tu utilises grep pour choper la colonne N, je comprend que tu aies quelques soucis avec le système actuel.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par Moonz . En réponse à la dépêche Projet Lumberjack. Évalué à 6.
man rsyslog.conf
Personne ne nie qu’un standard soit une bonne idée. Simplement, il existe déjà (c’est syslog), et vouloir utiliser du XML pour des logs, c’est, pour le dire poliment, pas particulièrement attirant.
« Écrivez des programmes qui traitent des flux de texte car c'est l'interface universelle »
Universelle, dans le sens : je peux utiliser la puissance d’outils comme sed/awk/grep/perl et des centaines d’autres, testés, éprouvés depuis des dizaines d’années, enseignés dans les plus mauvaises écoles d’administration système, installés sur virtuellement tous les systèmes, et qui ne me feront jamais faux bond, en les combinant d’une manière à laquelle personne d’autre n’a pensé parce que tout le monde s’en fout tellement mon problème est spécifique. Si tu me dis que je dois écrire un programme en Java avec un parser SAX pour résoudre mon problème spécifique, je te ris au nez (encore une fois, c’est la version polie).
[^] # Re: Du XML ?
Posté par Moonz . En réponse à la dépêche Projet Lumberjack. Évalué à 6.
Tiens, pourquoi /usr se monte plus ?
Oups…
[^] # Re: C'est pas pour toi
Posté par Moonz . En réponse au journal Chronique d'un flop annoncé. Évalué à 4.
Oui, si tu peux pas utiliser SIP Communicator (ou autre) sur ton laptop, c’est grave.