Go devient plus stable : de nouvelles versions de Go sortent régulièrement, en moyenne une fois par semaine. C’est un rythme soutenu qui ne convient pas à tout le monde. Les développeurs de Go ont donc décidé de continuer ces versions sous le nom de weekly, mais de publier également des versions stables tous les un à deux mois. Ces versions seront soigneusement choisies et annoncées sur la nouvelle liste, golang‑announce.
Gorun est un outil qui permet de lancer en ligne de commande des « scripts » écrits en Go. Il suffit de mettre « #!/usr/bin/gorun » en 1re ligne ([[Shebang]]) pour que le script écrit en Go puisse être lancé directement.
Cgo est un outil qui permet de compiler du code Go qui utilise des bibliothèques en C. Il fonctionne, pour le moment, avec le compilateur Go de Google, mais il est aussi prévu de prendre en charge le back‑end Golang de GCC.
Pour rappel, le langage Go (sous une licence de type BSD) est issu d'une discussion entre Ken Thompson (un des auteurs d'Unix et d'UTF8) et Rob Pike (un des auteurs de Plan9 et d'UTF8). Rob Pike a pu monter une équipe chez Google pour travailler dessus, et en novembre 2009, une première version a été dévoilée au reste du monde.
Aller plus loin
- Go, le site officiel (787 clics)
- Go devient plus stable (83 clics)
- Utiliser du code C depuis Go (136 clics)
- Gorun (80 clics)
- Les dépêches DLFP sur Go (170 clics)
# c'est moi ou bien...
Posté par cho7 (site web personnel) . Évalué à 10.
petite aparté...
c'est moi qui vieillit (27 ans !) ou bien ce langage est quand même assez compliqué ? car j'ai appris un tripotée de langages bizarres dans ma vie, je parle couramment le java/j2ee, le python, le flex/actionscript (pas taper, c'est pour le taf), j'ai joué avec lisp, scala, et plus récemment le erlang (rigolo ce truc pour les communications interprocessus), dont il parait que le go s'inspire, mais je suis désolé : le go ca me pique les yeux.
Et c'est le même constat avec le framework android, de nos amis googliens également, et qui se veut pourtant (il parait) être super neuneu-friendly.
Alors soit je vieillis et je rentre dans la période de ma vie où j'intègre désormais moins bien les choses (ce qui me fait peur !), soit c'est vraiment des trucs compliqués.
A qui s'adresse ce langage ? quand je vais sur http://golang.org/doc/go_tutorial.html je pense que le deuxième exemple (la commande echo) larguerait pas mal de monde déjà. Et puis tous ces dé-référencements là, beurk.
Désolé, c'était le commentaire inutile du jour, mais fallait que ca sorte...
[^] # Re: c'est moi ou bien...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Mon impression sur go était qu'il faisait des chevaux plus rapides selon le mot de Ford sur l'innovation ("si on écoutait les clients, ils voudraient des chevaux plus rapide").
j'ai l'impression d'un C dépoussiéré sans vraiment de truc vraiment sympa en plus.
"La première sécurité est la liberté"
[^] # Re: c'est moi ou bien...
Posté par vince74 . Évalué à 2.
Ceci dit c'est déjà intéressant en soi.
Apparemment c'est du côté du multitâches/multicore qu'il y a des choses intéressantes, je crois avoir vu que le langage était développé avec ça en tête.
Par contre le nom Go est vraiment une plaie pour les moteurs de recherche...
[^] # Re: c'est moi ou bien...
Posté par zebra3 . Évalué à 2.
Pas vraiment, la requête « Google Go » donne pas mal de résultats en rapport.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: c'est moi ou bien...
Posté par DLFP est mort . Évalué à 3.
Pas terrible d'associer un langage avec une compagnie. Et puis on pourrait se retrouver avec un changement de nom, comme « Sun Java » vers « Oracle Java ».
Le mot à utiliser ne serait pas plutôt golang ?
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: c'est moi ou bien...
Posté par MarbolanGos (site web personnel) . Évalué à 3.
Et encore le pire c'est le D !
[^] # Re: c'est moi ou bien...
Posté par pititjo . Évalué à 2.
Le R est pas mal non plus dans le genre.
[^] # Re: c'est moi ou bien...
Posté par Kerro . Évalué à 7.
Celui qui sort un langage nommé Super EXtensible, ça va être très très difficile pour faire le tri :-)
[^] # Re: c'est moi ou bien...
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Il existe un autre langage monolettre méconnu, le "C".
[^] # Re: c'est moi ou bien...
Posté par Sylvain Sauvage . Évalué à 3.
Et il y a encore quelque temps (ou sur quelques moteurs de recherche), les symboles, comme le ++ du C++ ou le # (ou ♯) de C#, ne passaient pas…
[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . Évalué à 10.
Non, tu n'es pas seul. Je trouve sa syntaxe vraiment bizarre. Il y a plein de choses que j'aime pas, notamment
make, l'omission des parenthèses (autour de la condition duifpar exemple) qui rendent le code difficilement compréhensible, la différence array/slice, le mélange entre pointeurs et références cachés (comme lesmap) qui fait que suivant le truc, l'argument est passé par valeur ou par référence, legoto, la précédence des opérateurs simpliste qui fait que3 * 2 << 2n'est pas égal à2 << 2 * 3(alors que dans la plupart des autres langages, c'est le cas)...Bref, beaucoup d'inconvénients pour peu d'avantages (pour moi, un gc n'est pas un avantage).
[^] # Re: c'est moi ou bien...
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 9.
C'est toi qui vieillit !!! Simplement, on devient de moins en moins open et de plus en plus critique avec les années. Forcément avec 10 ans de plus que toi, j'en arrive aux questions suivantes :
1. En dehors d'être estampillé Google, ça sert à quoi ?
2. Avec des définitions de variables à la Visual Basic et une syntaxe plus ou moins proche du C (avec des parenthèses en moins pour que ce soit moins lisible) et des trucs particulièrement abscons comme la gestion des slices, avait-on vraiment besoin de ça ?
[^] # Re: c'est moi ou bien...
Posté par kimelto . Évalué à 2.
avec des parenthèses en moins pour que ce soit moins lisible : comme python j'ai envie de dire, et pourtant on s'y fait a l'usage. Comme les declarations de types "a l'envers".
gestion des slices : c'est une fonctionnalite tres puissante pour obtenir un sous tableau sans copie! En C si tu veux zapper le debut d'une string tu incrementerais le pointeur, ici tu fais str[2:] pour zapper les 2 premiers chars. Si tu veux t'arreter avant la fin tu doit soit modifier ta string et ajouter un \0 avant la fin, soit creer une nouvelle string. Ici tu fait str[:8]. Et bien evidemment tu peux faire str[2:8]. Le seul desavantae c'est que si tu as une slice de deux elements qui a un array de 10000 elements derriere, l'array source restera en memoire jusqu'a ce que tu n'utilises plus la slice.
[^] # Re: c'est moi ou bien...
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 6.
Le problème, c'est de devoir s'y faire et donc de ré-apprendre un nouveau truc dont l'utilité est limitée
Un peu comme ce qui se fait en Ada sauf que ça date de 1983...
Désolé, je suis trop vieux donc toujours pas convaincu ;-)
[^] # Re: c'est moi ou bien...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
c'est une fonctionnalite tres puissante pour obtenir un sous tableau sans copie!
Quel est l'intérêt de mettre ça dans le langage? Ca a plutôt sa place dans une bibliothèque (comme les maps d'ailleurs).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: c'est moi ou bien...
Posté par CrEv (site web personnel) . Évalué à 8.
et pourquoi aller mettre ça dans une bibliothèque ? Pour en faire un énième langage sous puissant sans l'aide des dites lib ?
Je trouve au contraire que ce genre de chose doit faire parti du langage. Sinon on se retrouve avec des langages qui ne sont pas capables de faire un join sur un tableau de string (genre java, un langage qu'il est pauvre)
[^] # Re: c'est moi ou bien...
Posté par barmic . Évalué à 4.
Ça t'arrive souvent d'utiliser un langage sans sa bibliothèque standard ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: c'est moi ou bien...
Posté par claudex . Évalué à 4.
Le gros avantage, c'est que ce soit inclut dans la syntaxe et qu'on ne soit pas obligé d'écrire un truc du genre
arr.getFromTo(2,4).« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: c'est moi ou bien...
Posté par barmic . Évalué à 4.
Ouai, mais non ce n'est pas parce que tu prends pour exemple des langages qui n'ont pas suffisement de souplesse syntaxique que c'est toujours le cas. C++ avec la surcharge des opérateur permet d'implémenter dans des bibliothèques des trucs du genre :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: c'est moi ou bien...
Posté par CrEv (site web personnel) . Évalué à 7.
réponse courte : oui
réponse longue : si l'utilisation d'un langage est liée à l'utilisation d'une lib (le standard me fait malheureusement doucement rigoler...) alors il n'y a pas de raison que ce ne soit pas inclus par défaut.
Le problème inhérent est que si c'est pas réellement lié alors on se retrouve avec une multiplication inutile, par exemple en C++ on peut trouver des implémentations de listes dans de nombreuses libs différentes. Par certains côtés stl, qt, boost sont redondants. Et qui dit multiplication dit tests, bugs, failles, etc.
Et comme dit un peu plus bas (enfin pas comme ça) faudrait évoluer quand même. Créer un langage sans map, listes, opérations sur tableaux, etc serait franchement idiot. Pourquoi se limiter à un langage pauvre ? Un langage n'est pas qu'une syntaxe, le fait d'avoir des structures de haut niveau intégrées dans la langage est justement important.
[^] # Re: c'est moi ou bien...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Je vais encore parler de Lisaac mais tu peux avoir un langage syntaxiquement très limité et pouvoir tout faire avec en lib (même les if ou les while).
L'avantage est d'avoir un compilo très simple. Mais cela impose une vrai lib standard.
"La première sécurité est la liberté"
[^] # Re: c'est moi ou bien...
Posté par barmic . Évalué à 2.
Prenons java, tu pense que awt ou swig devrais faire partie du langage ?
J'ai un avis totalement contraire au tiens, pour moi le maximum de choses devraient être implémentée dans la bibliothèque standard. Si tu choisi de ne pas l'utiliser bien à toi, mais c'est utilisable par tous.
Si dans un langage objet tes conteneurs ne sont pas des classes (vu qu'elles sont inclu dans le langages), tu ne peux pas les dériver pour faire tes propres implémentations (alors oui il y a des techniques comme le duck typing, le pattern matching, etc), mais tu te retrouve à devoir ajouter un pan entier dans le langage pour simplement sous prétext d'obliger les utilisateurs à utiliser ce que toi tu pense qui est bien.
Tout avoir dans des bibliothèques c'est aussi donner de la liberté aux développeurs (tu vois tu n'utilise pas toujours les bibliothèques standards). C'est complexifier le langage (le travail pour porter le compilateur ou l'interpréteur est plus important). Tu es aussi obligé de faire évoluer le langage pour modifier des choses simples.
Bref je sais que c'est une discution interminable, mais il y a des raisons valables qui font implémenter les choses dans le langages ou non (en fait pour moi c'est un peu comme les noyaux, tout ce que l'on peut mettre hors du noyau doit l'être).
Pour parler de Java, c'est la bibliothèque standard qu n'évolue pas assez, ce n'est pas de la faute du découpage langage / bibliothèque.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: c'est moi ou bien...
Posté par CrEv (site web personnel) . Évalué à 3.
le problème de java c'est pas ça, c'est juste que c'est un mauvais langage, pauvre, avec aucune évolution réellement intéressante (que ce soit dans le langage ou dans la lib)
ça, c'est fait !
Sur le reste, comment dire ... j'ai bien peur de ne rien avoir compris à ce que tu racontes...
Lesquelles ? Et comment font les autres langages qui incluent beaucoup plus de choses ?
Attends, là on parle de map et d'opérations sur les tableaux. Je n'ai jamais dit que tout devait être dans le langage, il y a bien une séparation. Mais que les map ne fassent pas partie d'un nouveau langage me semble simplement très dommage. Tout comme un langage ne permettant pas de faire un join sur un tableau de string (c'est pas comme si c'était utile...)
Ha mais je ne les utilise pas toujours car il y a toujours quelqu'un pour faire un choix différent puisqu'il n'y a pas une bibliothèque réellement standard (pour prendre C++).
Bon, ben je crois qu'il faut que tu quittes linux pour passer sur un vrai micro kernel alors...
[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . Évalué à 3.
Un langage pour les gouverner tous... ça n'existe pas !
Que les tableaux et les maps (et les chaines de caractères) soient intégrés dans un langage de script, ça ne me choque pas, au contraire, je dirais que ça simplifie la vie. Mais que ce soit intégré dans un langage bas niveau comme le C ou comme veut l'être Go, non merci. Quand on utilise un langage bas niveau, c'est pour pouvoir tout contrôler et optimiser là où il faut. Un join sur un tableau de string, ça peut très bien se faire en C de manière très optimisée, sans doute bien plus rapidement que n'importe quel langage qui intègrerait tout.
[^] # Re: c'est moi ou bien...
Posté par Thomas Douillard . Évalué à 4.
Bah tu peux faire les même optimisations dans le compilateur, si il connait bien la sémantique et le matériel. C'est d'autant plus facile que si c'est dans le langage la sémantique est très bien connue du compilateur, il peut l'implémenter comme il veut.
[^] # Re: c'est moi ou bien...
Posté par barmic . Évalué à 1.
Ah tu commence à te chauffer :) c'est bien.
Ouah ! Comment t'es trop fort ! C'est fou le nombre d'imbécile sur cette terre ! Il est de notoriété que chez Apache par exemple, c'est vraiment des imbéciles ؟
Je continue ?
Les structures de données (domaine où il est impossible d'être exhaustif), les threads (ou tout autre manière de supporter du multitâche), gestion du réseau,.... tu t'arrète où ? AWT fais parti de la bibliothèque standard de Java.
A bon ? Linux n'est pas un micro noyau ؟
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: c'est moi ou bien...
Posté par CrEv (site web personnel) . Évalué à 5.
Là, je pense que tu te trompes de problème et que tu ne m'a pas compris (oué bon, ok, je pourrais rentrer plus fort mais il n'y aurait plus rien pour demain...). Java a des qualités. Mais java en tant que langage est à la rue totale. La java est un langage pauvre, où on ne peut pas faire grand chose de base. Par exemple, on ne peut pas surcharger les opérateurs qu'on souhaite ! Les "generic" on mis un tant fou à arriver. Et toute évolution du langage (je parle pas de ce qu'on peut avoir dans les libs) et d'une lenteur effroyable (on dirait jabber en fait)
Microsoft au contraire, avec C#, réalise un assez bon boulot car ils ont beaucoup moins de contraintes que java, et s'en pose beaucoup moins.
Il n'y a qu'à voir par exemple la partie
awaithttp://www.wischik.com/lu/AsyncSilverlight/AsyncSamples.html (c'est moche, faut silverlight, vous n'avez qu'à passer sous l'OS terreux) ou http://www.google.fr/search?sourceid=chrome&ie=UTF-8&q=white+paper+asynchrony+.net (oué faut un lecteur de docx)Java à côté n'avance pas vraiment... d'où d'ailleurs de nombreuses lib externes (apache en a des pas trop mal) mais c'est bien parce qu'on est obligé. Le problème est qu'entre le soft qu'on écrit et la lib qu'on utilise, les deux n'ont pas les mêmes libs par exemple. Et ça devient le merdier, consommation disque, mémoire, toussa.
lapin compris
Et pour le côté se marier entre différentes libs ... ça c'est une utopie
Et ça sert à quoi ? Je veux dire, en vrai ? Et d'ailleurs ça change quoi que ma map soit dans un lib ou dans le langage à ce niveau ? Si j'ai deux compilos ok, ben les deux compileront ma map.
lapincompris la relation avec la lib
latoujours pas compris le lien avec la lib et le langage
Après les map
Ha non, point du tout. Les tirades entre Torvalds et Tanenbaum sont pourtant suffisament célèbres (et si tu ne les connais pas tu peux les lires, c'est sympa).
On est plutôt sur un kernel hybrid, un bon monolithique qu'on modularise.
http://fr.wikipedia.org/wiki/Noyau_monolithique#Diff.C3.A9rents_types_de_noyaux est plutôt intéressant sur ce point
[^] # Re: c'est moi ou bien...
Posté par barmic . Évalué à 1.
Nous sommes d'accord sur Java. Tu remarqueras que deux des langages les plus populaires qui soient C et Java sont extrêmement pauvre. Pour les deux ça fait partie de leur force j'ai l'impression. Leur pauvreté permet de travailler au dessus et d'en faire des tas de choses.
La possibilité pour un langage objet de se faire sa propre implémentation d'un conteneur tout en héritant du conteneur standard et donc avoir une compatibilité avec tout les algorithmes existants.
En vrai, ça sert actuellement à avoir des alternatives aux implémentations faites par Oracle des différentes technologie Java. Ca peut servir à être plus indépendant. Ca permet par exemple d'avoir plusieurs libc certaines plus performante que d'autres, d'autres mieux prévus pour l'embarquée. Le tout s'en avoir à réécrire un compilateur à chaque fois.
Il met arrivé plusieurs fois d'aller voir dans les sources de la bibliothèque standard du C++ voir comment ils avaient implémentés certaines choses. C'est pas toujours facile quand tout est dans l'interpréteur/compilateur. Surtout que du coup ils ne se gènent pour utiliser des mécanise dont toi, en tant qu'utilisateur tu n'a pas accès.
Ah! Ah! Et si ton voisin veut des matrices ? Et que le voisin du voisin veut des matrices creuses ? ....
Waow ! Mais comme tu sais trop de choses !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: c'est moi ou bien...
Posté par CrEv (site web personnel) . Évalué à 3.
On peut voir ça comme une force, mais trop souvent ça se pert en complexité, en multiples implémentations différentes, incompatibles entre elles, dont aucune ne couvre tout à fait la même chose mais toutes se marchent dessus.
Mais c'est pas parce que ça fait partie du standard du langage que c'est forcément au niveau du compilo.
Ben tu voulais quoi d'autre comme réponse ? Pourquoi s'arrêter avant la map ? Pourquoi s'arrêter après ?
Je sais pas trop comment ça doit être pris.
Mais voici en tout cas des discussions intéressantes. C'est très célèbre comme discussion, ça date de 92 et en gros Torvalds dit que les microkernel c'est tout pourri alors que Tanenbaum dit que c'est génial (version courte).
[^] # Re: c'est moi ou bien...
Posté par barmic . Évalué à -6.
C'est le problème quand on laisse de la liberté aux développeurs.
Et tu l'implémente comment, alors ?
C'était la réponse que j'attendais. Tu as ta vision et tu veut que les langages suivent ta vison à toi.
Comme quelqu'un qui se fout de ta gueule depuis plusieurs commentaires déjà.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: c'est moi ou bien...
Posté par pasScott pasForstall . Évalué à -3.
Et pourtant, Java a un truc foutrement utile que quasiment personne n'a, les annotations.
Ne pas pouvoir surcharger les operateurs, tant mieux. Dans le genre feature a la con tres dangereuse juste parce que ca peut etre utile parfois ici ou la, et encore, pas toujours en fait, ca s'impose.
Consommation disque? Wow, t'es vraiment a 20ko pret?
Pour la memoire, ok, mais venant de passer du Java a l'objective c, ben t'sais quoi? Ne pas passer 2 soirees entieres a traquer les fuites memoires cette semaine, ca m'aurait bien arrange. Question de compromis, les deux se tiennent.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: c'est moi ou bien...
Posté par yellowiscool . Évalué à 3.
L'objective C, ça n'a pas un ramasse miettes en option justement ?
Envoyé depuis mon lapin.
[^] # Re: c'est moi ou bien...
Posté par pasScott pasForstall . Évalué à -2.
Pas sur les telephones et tablettes tant honnies, trop couteux pour ces ptites betes.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: c'est moi ou bien...
Posté par yellowiscool . Évalué à 4.
Et pourquoi ce serait moins coûteux sur un ordinateur de bureau ? Parce que l'on a 2Go de ram au lieu de 256Mo ?
Au passage, ça m’énerve toujours les ramasses miettes qui pensent qu'ils sont les seuls sur la machine. C'est pas parce que t'as 2Go de ram que t'as envi que java t'en prenne 2Go.
Envoyé depuis mon lapin.
[^] # Re: c'est moi ou bien...
Posté par pasScott pasForstall . Évalué à -4.
Parce qu'un ordinateur a un swap, un iphone n'en a pas.
Parce qu'un telephone tourne sur batterie et qu'il faut donc limiter au maximum ce qui tourne dessus.
Sinon, ya de tres bonnes raisons de preferer un gc, notamment pour les applis censees tourner longtemps, par exemple eviter la fragmentation de la ram. Au final, tu consommeras moins avec un gc.
Le truc c'est que les applis mobile sont tres differentes d'applis desktop. Faut que ca demarre instantanement et tu peux pas te permettre un temps de chauffe de jvm ni des pauses de gc, et le cycle de vie est le plus souvent tres court (sorti des qq applis genre mail, safari et calendar).
Sinon, tes 2 go de rm, ils sont fait pour etre consommes. De la ram libre ne fera pas tourner ton systeme plus vite.
Je prefere avoir mes 2go pleins en permanence plutot que de passer mon temps a lire depuisnun disque (potentiellement fragmente). Les ssd vont peut etre changer la donne, mais on en est pas encore la.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: c'est moi ou bien...
Posté par lasher . Évalué à 3.
Dans une optique de performance, je suis tout à fait d'accord. Dans une optique de gestion et d'économie d'énergie, on veut pouvoir éteindre une partie de la RAM quand elle ne sert pas. Même sur une machine type PC (je pense aux portables par exemple).
[^] # Re: c'est moi ou bien...
Posté par pasScott pasForstall . Évalué à -3.
Donc tu preferes aller chercher des libs sur le disque ou devoir recharger en permanence une page rendue par FF sur le disque plutot que consommer un pouilleme pour garder la ram en etat?
Quand je vois la duree de vie d'une batterie en veille par rapport a celle quand le disque est en activite, je suis pas sur que tu gagnes grand chose.
Note qu'avec un ssd, la donne est pas forcement la meme (ou peut etre que si, j'en sais rien), mais ca me parait difficilement tenable comme position de preferer un medium de stockage particulierement lent et consommateur a un tres rapide et consommant tres peu, que ca soit pour les perfs ou la conso.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: c'est moi ou bien...
Posté par lasher . Évalué à 2.
Non, c'est justement là où on voit apparaître le buzz-word « self-awareness » un peu partout. L'objectif est que ton OS (ou un sous-système dans ton OS) surveille en permanence l'état de la machine. En fonction des buts choisis par l'utilisateur (« performance », « économie d'énergie », « performance, mais si j'arrive à ~20% de ma batterie, économie d'énergie », etc.), le système peut décider de ce qu'il veut éteindre, réduire la tension sur certaines parties du processeur, etc.
Ça ne veut pas dire que tu vas forcément swapper comme un malade. Le système peut (par exemple hein) réactiver des portions éteintes de la RAM au fur et à mesure que tu as besoin de beaucoup plus de mémoire (« beaucoup plus » est à définir bien entendu). D'autre part, si je suis en mode économie d'énergie, je dois m'attendre à une machine moins rapide, donc j'ai envie de dire qu'instinctivement je vais moins en demander. C'est simple: sur mon eeepc, je ne cherche pas à lancer mplayer, firefox+20 onglets, et gimp (même quand je branche un clavier externe et une souris, ainsi qu'un écran externe). C'est pas qu'il peut pas le faire, c'est juste qu'un processeur Atom c'est pas très puissant, même à pleine puissance.
J'estime que lorsque tu entres en mode « économie d'énergie », tu entres aussi en mode « économie sur l'utilisation ».
Et si tu crois que c'est totalement inutile, je te propose de reconsidérer un peu. On pense atteindre l'étape de « l'exascale » (10³ × Petascale = 10⁶ × Terascale = ... :-)) d'ici à 2018-2020. Un superordinateur ça consomme de nos jours entre 2,5 et 5 MW (refroidissement compris). Même avec la meilleure volonté du monde, obtenir un ordinateur qui crache de l'exaflop (donc 10¹⁵ operations flottantes par seconde) et qui ne consomme pas entre 60 et 80 MW, je ne vois pas comment c'est possible. Tu penses bien que les gros centres de recherche (CEA, DARPA, etc) voudront éviter de devoir payer la facture pour une consommation « plein pot » quand la plupart du temps, on a juste besoin d'une fraction de la puissance de ce genre de machine. Or, ce qui consomme beaucoup sur un processeur et une carte-mère, ce sont la mémoire cache et la RAM.
[^] # Re: c'est moi ou bien...
Posté par barmic . Évalué à 2.
Il y a un monsieur très compétant qui disait qu'avoir un mode économie d'énergie et brider son CPU était d'une profonde inutilité, parce que si tu divise la fréquence de ton processeur par 2, tu multiplie le temps de calcul par 2, mais tu ne divise pas la consommation par 2. Pour lui ce qu'il faut (et ce qui essaie d'être fait), c'est de pouvoir switcher entre les états d'endormissement de plus en plus vite.
De la même manière éteindre la RAM (si tenté que ce soit possible), n'est pas une idée terrible je pense, tu va avoir des seuils et le swap est extrêmement consommateur (ça ralentis la machine et ça fait tourner le disque dur). On pourrait imaginer changer la fréquence de la RAM, mais je ne suis pas sûr que ça ai beaucoup de sens (et ça na pas de rapport avec l'occupation de RAM que tu as).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: c'est moi ou bien...
Posté par nicolas . Évalué à 3.
T’as tout faux. Moins tes applis consomment de RAM moins tu auras d’accès disque : plus de RAM disponible pour le cache. Et présentement, de la RAM libre fait tourner ton système plus vite, pour s’en convaincre il suffit de lancer une application une seconde fois juste après la fermeture, puis après avoir vidé le cache. Autre exemple : je mets mon swappiness à 100, car il est plus avantageux de « perdre » une lib. de l’espace mémoire que du cache disque.
Et puis dans le desktop aussi j’aimerai que mes applis démarrent instantanément.
[^] # Re: c'est moi ou bien...
Posté par djano . Évalué à 1.
Non plus! Un noyau hybride c'est ce qu'il y a dans MacOS X ou il y a un micro-noyau Mach sur lequel on a mis le noyau monolithique de FreeBSD.
[^] # Re: c'est moi ou bien...
Posté par CrEv (site web personnel) . Évalué à 2.
c'est vrai, d'ailleurs le lien fourni l'explique plutôt bien.
par hybride dans la phrase je voulais plutôt dire qu'on est ni sur un micro kernel, ni totalement sur un monolithique (mais c'est vrai que c'est différent d'un kernel hybrid)
[^] # Re: c'est moi ou bien...
Posté par djano . Évalué à 1.
Ah! Je n'avais pas vu ça en lisant l'article.
Linux est généralement classifié comme un noyau monolithique modulaire. Ce qui est quand même bien mieux que monolithique pas modulaire :)
Je ne sais pas ce qui joue le plus pour le coté modulaire? Une claire séparation entre les composants? (VFS, FS, IO scheduler, process scheduler, gestion de la mémoire, etc.) Ou bien une claire séparation entre les drivers? Ou bien la possibilité de configurer différemment la compilation pour obtenir un noyau le plus petit et adapté possible pour son matériel. C@est peut être un peu tout ça a la fois.
[^] # Re: c'est moi ou bien...
Posté par ecyrbe . Évalué à 3.
C'est plutôt le fait que les drivers/extensions du kernel sont pluggé comme des modules. On peut de plus enlever et ajouter des modules à la volé. C'est ça la modularité...
[^] # Re: c'est moi ou bien...
Posté par lasher . Évalué à 5.
Oui alors euh, justement, pour les threads, il y a de très bons articles (je ne sais pas s'ils sont disponibles librement sur le net) qui expliquent que par exemple les threads ne devraient pas être implémentés dans une bibliothèque. Par exemple, Threads Cannot not be Implemented as a Library a été écrit par J.Boehm, l'un des concepteurs du modèle mémoire du prochain standard de C++. The Problem with Threads, écrit par E.A. Lee, explique bien les problèmes liés à la façon dont le parallélisme dans les langages actuel est généralement mal exprimé et donc exploité.
Je suis totalement d'accord avec cette vision des choses (et un jour, OoOooOoh oui, un jour, j'écrirai un journal sur ce thème). Tant que les threads (ou une quelconque façon de gérer le parallélisme) sera exprimé à coup de PThreads, tant que les compilateurs considéreront qu'ils optimisent pour des programmes mono-thread (et donc effectueront des transformations dangereuses), etc, alors on aura toutes les difficultés du monde à produire des programmes parallèles efficaces sans passer un temps fou à les debugger.
[^] # Re: c'est moi ou bien...
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Mais que les map ne fassent pas partie d'un nouveau langage me semble simplement très dommage
Quelles map? std::map? std::multimap? std::hashed_map? boost::bimap? LinkedHashMap? Si pour chacune tu as une syntaxe différente et une implémentation en dur dans le compilo, ce n'est pas très pratique.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: c'est moi ou bien...
Posté par djano . Évalué à 4.
Le problème de Java c'est que les gens aiment bien taper dessus sans rien y comprendre. Faut croire que toutes ces entreprises qui ont misé sur Java doivent être complétement connes et qu'elles n'ont rien compris.
Jamais tu ne t'es demandé pourquoi? Ce n'est pas le meilleur langage du monde, mais il ne mérite certainement pas un tel matraquage parce qu'il n'est pas aussi mauvais que tu le prétends.
[^] # Re: c'est moi ou bien...
Posté par yellowiscool . Évalué à 2.
La plupart des entreprises utilisent Windows. Même si ce système a des avantages, on est quand même assez nombreux ici à penser que c'est un mauvais choix.
Pourquoi ce serait différent avec un langage de programmation ?
Envoyé depuis mon lapin.
[^] # Re: c'est moi ou bien...
Posté par djano . Évalué à 1.
Il n'y a pas si longtemps on a dit ici même que Windows avec l'Active Directory n'avait pas d'équivalent dans le monde libre.
Donc, ne me fait pas dire ce que je n'ai pas dit: Je prétends que Java doit avoir quelques avantages sinon personne n'aurait parié autant dessus. Je n'ai pas dit que c'est bien parce que tout le monde en fait.
D'ailleurs crEv a souligné que sa critique portait sur le langage Java, et pas sur la plateforme. Et la, j'avoue qu'il a raison.
[^] # Re: c'est moi ou bien...
Posté par CrEv (site web personnel) . Évalué à 2.
Le problème c'est que tu n'as pas bien lu. La critique n'est pas sur la plateforme, la jvm (car les avantages de java sont ici, multi plateforme, performances - oui - de la jvm, etc) mais la critique est sur le langage java proprement dit. Et oui le langage java est pauvre, ne pas le voir c'est coder avec des oeillères.
C'est pas parce que beaucoup de monde fait une connerie que s'en est moins con (spa spécifique à java)
Si.
Java est un mauvais langage mais une bonne plateforme. Le problème c'est que, il me semble, tu confond ou agglomère les deux.
D'ailleurs je code en java, y'a des choses bien, mais des grosses lacunes. Ca ne m'empêche pas de l'utiliser pour certaines qualités, mais pas pour la pauvreté de son langage.
[^] # Re: c'est moi ou bien...
Posté par djano . Évalué à 1.
Si tu parles du langage Java tel qu'il est actuellement, alors la effectivement il est a la ramasse. D'ailleurs il est clairement en train de devenir un langage legacy, un peu comme le C, avec des changements minimaux préservant l'existant logiciel.
Je me plaçais effectivement plus du coté de la plateforme.
[^] # Re: c'est moi ou bien...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
le standard me fait malheureusement doucement rigoler...
Les problèmes de "standard" arrivent aussi bien entre différentes bibliothèques et différents compilateurs.
Par exemple D gèrent les nombres complexes "dans le langage", mais:
Complex floating point operations may not work the same as DMD
http://dgcc.sourceforge.net/gdc/manual.html
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: c'est moi ou bien...
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
L'intérêt c'est de ne pas multiplier les syntaxes à apprendre.
Si je devais concevoir un langage, je préfèrerai:
à:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: c'est moi ou bien...
Posté par reno . Évalué à 3.
Ça existe déjà: ça s'appelle le LISP et la plupart des développeurs n'aiment pas sa syntaxe, l'autre extrême c'est APL&Perl qui sont très baroques et peu maintenable au final..
Donc il faut trouver un juste milieu: Scala est bien pour ça à mon avis..
[^] # Re: c'est moi ou bien...
Posté par gasche . Évalué à 5.
Dans la plupart des langages, les concepts "dans le langages" peuvent exploiter des informations et des outils auxquelles les bibliothèques externes n'ont pas accès. Les langages où ça ne se voit pas trop sont les langages dont le cœur est extrêmement minimaliste (je pense à Forth par exemple, où on a l'impression que rien n'est "dans le langage") et les langages qui insistent énormément sur l'extensibilité (comme Scheme; l'approche Racket est exemplaire dans le style "tout implémenter sous forme de bibliothèque", mais ça demande un travail considérable).
Concrètement, l'intérêt des slices "dans le langage" c'est d'avoir une syntaxe agréable pour gérer ça. Les opérations peuvent très bien être écrites de façon externe dans une bibliothèque, mais si on voulait une bibliothèque qui apporte ce sucre syntaxique il faudrait ajouter une facilité générale de sucre syntaxique dans le langage (par exemple une forme de surcharge des opérateurs), c'est tout de suite plus compliqué, il faut réfléchir, on risque de se planter et de faire des choix de conceptions qui plombent le langage pendant des années, etc.
Même topo pour les maps : c'est une structure de donnée indispensable dans un langage, car extrêmement utilisée, comme les listes et les tableaux; d'ailleurs une fois abstraites les considérations bas-niveau un tableau est essentiellement une map avec des clés entières au domaine restreint à être de la forme [0..N-1]. Pour l'ajouter sous forme de bibliothèque il faudrait ajouter une paramétrisation des types par les types, comme les types paramétriques des langages fonctionnels ou les "generics" des langages objet (essentiellement la même chose sous deux noms différents, si l'on exclu la template madness). Tu notes que ces types paramétrés sont les grands absents du langage de type de Go, puisqu'aujourd'hui tous les langages statiquement typés sont d'accord pour dire que c'est utile (on arrête avec les conneries
Objectouvoid*). Pourquoi ? Parce que les concepteurs de Go n'ont pas d'expérience dans ce domaine, pensent que c'est délicat et ont préféré ne rien mettre que mettre un truc cassé qui les engage dans le futur. Donc on ajoute les map en dur dans le langage parce qu'il y a un fort besoin et ont dit que pour le reste, on verra plus tard.C'est en cela que Go est un langage "minimaliste dans le style C" : pas de fonctionnalités compliquées qui pourraient poser des problèmes, on n'ajoute que des trucs utilisés depuis des années et bien maîtrisés, et si ça demande de faire des choix pragmatiques (inclusion des
mapen dur), on le fait.[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . Évalué à 4.
Bienvenue dans PHP ! Et tout codeur PHP sait tous les problèmes que ce genre de considération peut poser. Un tableau et une map, ce n'est pas la même chose. Ils n'ont pas la même utilité. Et on peut tout à fait les mettre les deux dans un langage sans les fusionner. Ce qui permettra d'optimiser certaines opérations suivant qu'on a un tableau ou une map.
[^] # Re: c'est moi ou bien...
Posté par gasche . Évalué à 1.
Oui, d'ailleurs tu notes le "essentiellement" (prendre de la distance) et le fait que ce n'est pas la même chose en Go.
Maintenant si tu pouvais me donner un exemple d'opération qu'on fait sur un tableau qu'on ne pourrait absolument pas faire sur un map dont les clés sont "énumérables" (ou carrément indicées par 0..N-1) et à accès en temps constant, et qui sont absolument indispensables, je suis intéressé.
[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . Évalué à 2.
Un tri... Sur un tableau, on a tendance à trier le contenu (trier les indices n'a pas grand intérêt), alors que sur une map, on triera plutôt selon les clefs (quand ça a un sens, ce qui n'est pas gagné).
[^] # Re: c'est moi ou bien...
Posté par gasche . Évalué à 1.
C'est vrai que l'opération "tri de la map de façon à ce que l'ordre des clés corresponde à l'ordre des valeurs" n'est pas très naturelle (parce qu'elle change les associations clé-valeur). Mais on pourrait très bien l'implémenter sur les maps de façon efficace.
Est-ce que la séparation map/tableau permet vraiment d'"optimiser" ça ? Si je définissais les tableaux dans mon langage comme des maps (qui respectent les contraintes déjà données), et implémentait cette opération de tri par dessus, il n'y aurait pas de problème, si ?
(Un truc que je vois c'est au moment du pretty-printing, on a envie de voir s'afficher par exemple
[|1;2;3|]plutôt que{0:1; 1:2; 2:3})[^] # Re: c'est moi ou bien...
Posté par Thomas Douillard . Évalué à 2.
La différence c'est une histoire de sémantique surtout, c'est la différence entre les collections "ordonées" (l'ordre d'insertion des éléments dans la collection est important : les tableaux, les listes) ou les collection "non ordonnées" : les ensembles, les maps (en général) ou ce qui est important c'est la présence plutôt que l'ordre.
[^] # Re: c'est moi ou bien...
Posté par Thomas Douillard . Évalué à 2.
En fait tu as parfaitement raison, un tableau peut parfaitement être vu comme une spécialisation d'une map, je retire mon message au dessus /o.
Après pour le pretty printing, la spécialisation empêche pas de le faire, les templates de C++ permettent de faire ce genre de trucs sans soucis (fonction générique dans le cas général, avec une implémentation particulière dans le cas ou le type des clés est un type entier) de même pour les opérations d'accès qui peuvent être spécifiques au type.
Dans tous les cas la sémantique clé -> valeur est respectée. Dans le cas d'un ordre, c'est effectivement moins naturel on a plutôt tendance à associer un rang à un élément plutôt qu'un élément à un rang, mais finalement la problématique est la même pour un tableau et ça ne pose de problèmes à personne.
[^] # Re: c'est moi ou bien...
Posté par gasche . Évalué à 3.
Merci (ça fait toujours plaisir :p ) mais, dans l'autre sens, je n'ai pas terriblement insisté sur la question parce que je trouve qu'à partir du moment où on utilise la spécialisation pour avoir une implémentation efficace ou le pretty printing qui convient, on a en fait deux concepts, les maps générales et un "cas particulier optimisé" qui est essentiellement un tableau classique "caché", et le fait de dire "mais c'est la même chose" n'a pas énormément de sens.
Par contre, ce qui a du sens et est utile, et que l'on peut obtenir par différentes méthodes, est de s'assurer que le tableau permet toutes les opérations que l'on a sur les maps. La technique "type map général + spécialisation" le permet, mais on pourrait aussi avoir les deux concepts séparés et proposer un "proxy" pour voir tout tableau comme une map (en implémentant les méthodes des maps par dessus les opérations des tableaux, plutôt qu'en convertissant les données, pour des raisons de performances temps et mémoire).
De toute façon, mon message initial qui a lancé tout ce débat était juste une remarque sur le fait que les maps sont utiles puisque les tableaux, qui sont une forme d'association clé-valeur, sont très utilisés. C'est vrai indépendamment de savoir si on peut implémenter les tableaux comme map, etc. Ceci dit, la discussion qui s'est ensuivie reste intéressante.
[^] # Re: c'est moi ou bien...
Posté par nicolas . Évalué à 4.
Et comment qu’on fait si on veut un tableau de réels en précision simple qui ne prenne pas le double de mémoire que la quantité théorique ?
Bon pour un développeur Java ça changera pas grand chose… ^^
[^] # Re: c'est moi ou bien...
Posté par Thomas Douillard . Évalué à 3.
Tu spécialises l'implémentation dans ce cas.
[^] # Re: c'est moi ou bien...
Posté par nicolas . Évalué à 2.
En fait ce que je voulais dire a été bien mieux dit que moi plus bas (j’ai répondu un peu trop vite). Un tableau n’est pas seulement une association clef entière–valeur. C’est une utilisation possible, mais c’est aussi « une suite d’éléments qui conserve l’ordre », ceci indépendament des indices attribués.
Du coup l’indice est annexe, tout ce qui peut m’intéresser dans un tableau c’est de pouvoir faire :
[^] # Re: c'est moi ou bien...
Posté par djano . Évalué à 1.
En gros tu veux une liste?
De rien :)
[^] # Re: c'est moi ou bien...
Posté par Étienne . Évalué à 5.
Les caractéristiques qu'on attend d'une map et d'un array ne sont pas les même, notamment en terme de complexité d'insertion/supression/accès aléatoire/.... On s'attend en générale à ce qu'un array soit stocké de façon continu (ce qui permet au passage de le passer facilement à une fonction en C qui prend un pointeur et une taille). Le choix d'un type de conteneur se fait souvent par rapport au coût en temps/mémoire par rapport à l'utilisation qu'on en a ; et de ce point de vu une map et un array ce n'est pas la même chose.
Étienne
[^] # Re: c'est moi ou bien...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Pour l'argument de la syntaxe agréable dans le langage, voir http://www.boost.org/doc/libs/1_42_0/libs/assign/doc/index.html
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: c'est moi ou bien...
Posté par pasScott pasForstall . Évalué à -2.
Super, retour en 1973, les chaines sont des tableaux.
Depuis cette epoque, on a invente les objets.
Ca donne par exemple:
[string substringFromIndex: 2];
[string substringtoIndex: 8];
Et attention, tres tres fort:
[string substringWithRange: NSMakeRange(2,8)];
(Note: l'api utilisee dans cet exemple a environ 20 ans, et tourne a peu pres aussi vite que l'equivalent en c).
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: c'est moi ou bien...
Posté par gasche . Évalué à 4.
C'est un post ironique, ou tu trouves sérieusement que
[string substringWithRange: NSMakeRange(2,8)]c'est beaucoup mieux questring[2:8]?Je suis d'accord avec le fait que présenter les chaînes comme des tableaux n'est pas une idée géniale, en regard des difficultés importantes soulevées par UTF, mais aussi par la supériorité en pratique de structure immutables et facilement concaténable comme les ropes pour les manipulations de chaînes. Mais je n'ai pas compris le sens de l'argument "les objets c'est mieux" (de toute façon dans la plupart des langages objets, les tableaux sont aussi des objets, donc bon...) et des exemples de code qui suivent.
[^] # Re: c'est moi ou bien...
Posté par pasScott pasForstall . Évalué à -3.
Oui.
Le premier me dit que ca me retourne un sous chaine avec le range passe en parametre.
Le deuxieme, j'en ai strictement aucune idee.
Si le parametre est nomme items par exemple, je sais meme pas ce que ca va retourner.
Probablement parce que les objets permettent de contourner gracieusement tous les problemes que t'as mentionne juste au dessus.
Les tableaux sont des objects, certes, mais je peux faire string[5]='t' sur une chaine que je suis pas cense modifier et me retrouver avec un beau depassement de pointeur en cadeau bonux.
Bon courage pour faire pareil avec un object.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: c'est moi ou bien...
Posté par gasche . Évalué à 5.
Si les tableaux sont des objets, on peut "faire pareil" avec des objets, par définition. Tu n'as pas l'impression de te contredire ?
Le problème n'est pas de savoir comment sont stockées les données en mémoire, mais quelle interface tu fournis pour les manipuler. Si tu donnes à ton objet la même interface qu'un tableau, tu as les mêmes problèmes qu'avec un tableau, la concision de la syntaxe en moins.
Par exemple, les "problèmes UTF" que j'ai cité viennent du fait que, pour des chaînes UTF, la sémantique de l'indexation des caractères n'a pas vraiment de sens : quand tu dis str[1], ça peut vouloir dire le deuxième octet, ou le deuxième code point, et ça peut dépendre de quelle genre de normalisation est utilisée. Le problème fondamental c'est d'imaginer que tu as une opération d'accès à un index donné. Si ton objet te permets d'écrire des 'subrange' délimitées par des indices numériques, ça va poser des problèmes avec Unicode, tout autant que les 'slices' de Go.
De même, c'est évident mais si ton objet ne fait de vérification quand tu accès à un indice de la chaîne, il peut provoquer des segfault aussi.
Le fait de dire "c'est un objet" ne change rien et n'apporte rien, la question est de savoir quelle est l'interface proposée, et quel est le comportement garanti (vérifications d'accès ou pas, etc.).
[^] # Re: c'est moi ou bien...
Posté par pasScott pasForstall . Évalué à -3.
Le truc c'est que justement, la specialization permet de lever l'ambiguite. C'est bien parce que c'est une chaine que substring va travailler sur des caracteres, le contexte leve l'ambiguite, chose que tu peux pas faire avec un tableau.
Si tu veux acceder au bytes directement, ben [string bytes] te retourne ton tableau de bytes, le monde est bien fait.
Et les operations sur une chaine ne se limitent pas aux sous chaines simple, un lowercaseString, replcaement de chaines, regex et compagnies, ca t'abstrait des chaines terminees par 0 (ce qui est fait est le meme pb que l'utf8).
Si tu commences a definir substring sur ton tableau, ton api va commencer a etre bizarre, non?
Alors bien sur, tu peux definir ca comme une fonction qui prend un le tableau en parametre, mais tu perds le typage (tu peux passer un tableau d'entier) et l'immutabilite. A moins que tu commences a faire des tableaux immutables, mais la, c'est la porte ouverte a toutes les fenetres.
L'objet va rendre les choses explicites (ton objet est une chaine de caracteres dont les operrations sont definies) plutot qu'implicite (il se trouve que ton tableau represente une chaine, et donc tu dois savoir que la chaine se termine par 0 et que sa taille est donc taille du tableau - 1).
Je pensais que tout le monde avait compris avec l'experience du C que ls chaines definies comme tableau, c'etait mal?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: c'est moi ou bien...
Posté par gasche . Évalué à 1.
J'espère ne pas être blessant ou vexant en disant ça, ce n'est pas du tout mon intention, mais je pense effectivement que c'est un manque de connaissances de ton côté. En connaissant C et un peu Lisp, Scala et Erlang, il ne devrait pas y avoir grand chose qui pose vraiment problème dans Go.
Peut-être que ton problème c'est que les langages que tu connais bien ne sont en fait pas tellement différents. Ce sont des langages objets, ce qui n'est le cas¹ de Go, et python et {action,java}script sont très proches sémantiquement (il y a la différence entre l'OO à classes et l'OO à prototypes, mais bon...).
¹: en tout cas il ne propose pas d'héritage avec late binding, c'est-à-dire récursion ouverte.
Le mieux pour pouvoir apprendre facilement un nouveau langage est de se confronter à des langages plus variés comme par exemple Lisp, Prolog, OCaml, Haskell, Factor, Smalltalk, Erlang, ATS, Oz, etc.
Non, Go n'est pas complexe; en tout cas il est sensiblement moins complexe que C++, D ou même Java, qui sont pourtant considérés comme des langages utilisables par tout le monde. C'est plutôt un langage relativement "simple" dans la tradition de C.
Après, ça ne veut pas dire que tous les programmes écrits en Go sont simples, évidemment. En particulier tout ce qui touche à la concurrence comporte son lot de complexité, car c'est fondamentalement un domaine assez délicat.
[^] # Re: c'est moi ou bien...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Go a des fonctionnalités très intéressantes, mais cee qu'on lui reproche finalement, c'est de souvent changer pour changer.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: c'est moi ou bien...
Posté par cho7 (site web personnel) . Évalué à 3.
alors tu n'es pas vexant du tout, et je te rassure je n'ai pas dis que je ne comprenais pas le langage, mais qu'il me piquait les yeux.
Car oui, j'ai pissé beaucoup de code C dans ma vie, du Erlang également, mais la mode est aux langages simples et puissants, et je ne trouve pas Go particulièrement simple. Je dirai qu'il ressemble beaucoup à du C qui aurait forniqué avec d'autres langages un peu plus modernes, ce qui honnêtement n'est pas une bonne chose pour le vendre aux nouveaux développeurs en herbe.
Sinon pour répondre sur ta phrase
Et bien figure toi que je trouve ca super bien géré en Erlang justement, et de manière classieuse en plus.
[^] # Re: c'est moi ou bien...
Posté par cho7 (site web personnel) . Évalué à 2.
auto-citation :
bon, ok je l'ai un peu suggéré en disant que je vieillissais, mais j'exagérais juste un peu pour dire que, quand même, avant je m'extasiais devant la simplicité du python ou des processus Erlang, et que quand je vois Go je me dis juste : pffiou
[^] # Re: c'est moi ou bien...
Posté par gasche . Évalué à 2.
D'accord, c'était plus un jugement sur la syntaxe. Dans ce cas, c'est tout à fait normal : personne n'est familier avec une syntaxe ou une autre à la naissance, on s'y habitude. Pour les points qui sont proches des langages que tu connais, ça ne pose pas de problème, mais dès que c'est différent il y a une réaction initiale de rejet¹, et il faut du temps et de la pratique pour s'y habituer, mais au bout d'un moment ça vient.
¹: le rejet est facile à expliquer. L'important pour un programmeur est de comprendre rapidement la structure du code et sa signification, sans avoir à tout lire linéairement dans le détail. Quand on est habitué à la syntaxe on peut faire ça, mais sinon on a l'impression de voir du "bruit" et il faut faire bien soin de tout lire pour avoir une chance de dégager la structure d'ensemble. C'est donc une difficulté supplémentaire à l'abord d'un nouveau langage qui explique ce déplaisir du programmeur.
Je trouve cependant que les commentaires sur cette dépêche sont trop portés sur la syntaxe. La syntaxe ça compte, mais ce n'est pas non plus le plus important dans un langage, parce qu'à part certains choix extrêmes (whitespace, etc.) au final on s'y habitue et on ne s'en soucie plus. Je préfère discuter de la sémantique d'un langage, ses fonctionnalités, son expressivité; je regrette que la plupart des gens ici parlent beaucoup plus de la forme que du fond.
# Testez-le, ensuite vous pourrez critiquer
Posté par dohzya . Évalué à 8.
J'ai l'impression que les commentaires que j'ai pu lire sont uniquement des « vu d'ici j'aime pas », et je trouve ça dommage. Pour avoir un peu joué avec, je dois dire que j'aime beaucoup coder en Go, et j'ai la même impression de liberté que quand je code en Ruby (je parle bien de l'impression hein ! ça reste un langage à typage statique, donc plus restrictif).
La fonctionnalités que je préfère, c'est… le mécanisme des interfaces. Je défini mon interface, et c'est tout, je peux l'utiliser. Tous les types qui implémentent les bonnes méthodes implémentent implicitement cette interface (typiquement, tout type implémente l'interface vide). C'est la fonctionnalité dont je rêvais quand je codais en Java).
Ensuite c'est vrai que sa syntaxe change de C, mais c'est pour moi une force de ce langage. Typiquement, je suis bien content de ne pas avoir à me retaper ces foutues parenthèses à chaque conditions, alors que, encore une fois, le compilo n'en a pas besoin ! (ok, en C on peut écrire « if (test) stmt; » mais je trouve ça moche et traitre. Ensuite le « ; » dans le if parait très étrange au début, mais il permet d'écrire « if my_var = my_val ; my_var { », un équivalent de « if (my_var = my_val) { » qui supprime une ambigüité (voulait-on écrire « if (my_var == my_val) { » ?). Au final, ça change mais ne perturbe pas (on s'y fait très vite) et ça supprime certaines ambigüités : j'adore.
Bref, je ne suis pas en train de vous dire que c'est le meilleur langage de l'univers, mais vous devriez éviter de vous fixer sur des détails (« il ne ressemble pas à ce que je connais, mais il n'est pas assez différent de ce que je connais ») et lui donner sa chance.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
La fonctionnalités que je préfère, c'est… le mécanisme des interfaces.
Il est possible de faire cela en perl. J'ai entendu parler de ce genre de fonctionnalité sous le nom "type match" ou de "sub-typing". C'est une sorte d'inversion de l'héritage : pas besoin d'une classe mère pour partager un bout de code, du moment que l'interface est cohérent.
"La première sécurité est la liberté"
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par rewind (Mastodon) . Évalué à 4.
De même, les templates C++ sont équivalents aux interfaces Go, sauf qu'on ne déclare pas l'interface, on utilise des méthodes d'un type et on peut instancier le template avec n'importe quel type qui implémente les méthodes. La définition des interfaces devaient être incluses dans le nouveau C++ sous le nom de concept mais a été annulé.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par dohzya . Évalué à -2.
Ok, je ne connais pas assez les templates C++ (ni les interfaces Go) pour faire une comparaison efficace, mais il me semble qu'ils se rapprochent plus des macro C que des interfaces Java. Ok ils apportent un peu plus de souplesse, mais je vois ça comme un hack pour contourner les limites du typage du langage (on aurait pu faire leur boulot à la main à coup de macros dégueux). Je connais encore moins le mécanismes de concept C++, mais pour ce qu'en ai entendu, j'ai en effet l'impression qu'ils auraient été les équivalents des interfaces Go.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par barmic . Évalué à 6.
En effet tu ne connais pas assez les templates C++.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par BFG . Évalué à 3.
En Java, les templates demandent des informations sur les types paramétrés. Si l'on définit une classe ainsi :
alors le contenu de la classe ne pourra rien exploiter du type K (autre que ce qui est présent dans Object). La classe Generique est compilée une seule fois. Si on utilise la classe Generique<String> dans une classe Exemple, le compilateur utilisera Generique et fera quelques transtypages (à la compilation, pas à l'exécution) en plus depuis Object vers String.
Si l'on veut pouvoir utiliser des spécificités de K, comme par exemple utiliser une méthode charAt, il faudra définir une interface Caracteres à l'avance et définir ainsi :
En C++, une classe à template est recompilée pour chaque instanciation différente de template. C'est pour cela que les classes à templates doivent être placées dans des entêtes (.h, certains compilateurs ne sont pas restreints ici, mais ils sont rares). Comme la classe Generique n'est réellement compilée qu'au moment où le compilateur a les informations sur le type paramètre, et qu'un type dédié est créé, le compilateur fait les remplacement comme une macro, aucune déclaration d'interface n'est nécessaire. std::list<int> est une entité bien différente de std::list<bool>, contrairement à ArrayList<Integer> et ArrayList<Boolean> qui sont la même.
On pourra utiliser tous les types qui ont un opérateur "+" (et dont le prototype est en accord), sans besoin de déclarer de façon spéciale toutes les classes (sans interface à la Java) que l'on voudra utiliser avec "somme".
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par ecyrbe . Évalué à 3.
Exactement, quand j'ai vu les interfaces en Go je me suis tout de suite dit que j'avais déjà ça avec les templates en C++ ou en D. Cependant l'implémentation des interfaces Go ne me semblent pas claire. Quand est-ce que les mécanisme des interfaces sont ils résolu? à la compilation ou à l’exécution?
A la lecture de la documentation, j'en conclu que Go utilise des mécanisme dynamiques (résolution à l’exécution) et que les objets Go doivent embarquer une table virtuelle des méthodes pour permettre la résolution dynamique, voir plus lourds comme une table de signature de fonctions.
J'imagine quand même que quand la résolution peut se faire de manière statique (à la compilation), Go doit optimiser et éviter des appels à cette table, sinon, j'ai peur pour les performances.
Quelqu'un qui s'y connait dans l'implémentation des mécanismes de Go peut-il nous donner des exemple et nous pointer du doigt quand est-ce que la résolution se fait de manière statique et quand elle se fait de manière dynamique?
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par gasche . Évalué à 5.
Déjà, il est faux de dire (comme le faisait un post plus haut) que les interfaces de Go sont "équivalents" aux templates de C++. Équivalent, ça veut dire qu'on peut remplacer l'un par l'autre, et réciproquement. Mais il est absolument impossible d'utiliser les interfaces (concept relativement simple et à l'usage bien délimité) pour remplacer tous les usages des templates C++ (gros tas de fonctionnalité extrêmement complexe, sous-langage Turing-complet exécuté à la compilation).
Ensuite, votre préoccupation pour les performances de la résolution des méthodes est déplacée dans la majorité des cas. Les efforts d'implémentation du langage Self ont montré qu'on pouvait obtenir d'excellentes performances en optimisant un langage où toutes les résolutions sont dynamiques.
La description de l'implémentation actuelle des interfaces de Go est décrite par exemple dans ce billet (trouvé il y a 5 minutes sur Google). Si j'ai bien compris après lecture rapide, les tables sont calculées au moment de l'initialisation des objets, et ensuite les appels sont de simples appels indirects. On peut imaginer de nombreuses optimisations (des heuristiques pour faire des paris statiques sur la table à initialiser), mais il n'y en a sans doute pas besoin pour avoir des performances tout à fait raisonnables.
Et je ne joue pas l'air de flûte bien connu "les ordinateurs sont plus rapide, on peut avoir des langages plus lents". Mais à force de se focaliser sur des détails bas niveau sans grand intérêt, on se fossilise dans des conceptions dépassées qui sont au final moins performantes. Par exemple on a beau dire que la gestion manuelle de la mémoire en C ou C++ c'est top génial, et hurler dès qu'un langage se prétendant rapide intègre un GC, au final les gens qui codent en C ou C++ mais ne veulent pas des bugs absurdes liés à la gestion de la mémoire doivent se servir de bibliothèques de gestion de mémoire (shared_ptr, Boehm GC...) qui sont beaucoup plus lentes que ce qu'on fait dans un langage haut niveau bien compilé, parce que la sémantique du langage ne permet pas de faire ça de façon précise et performante.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par rewind (Mastodon) . Évalué à 2.
Je ne disais pas ça, je disais qu'avec des templates C++ (et les concepts qui ne font pas encore partie de C++), on avait un équivalent des interfaces Go. Certes, on peut faire beaucoup plus de choses avec les templates, mais je n'en ai absolument pas parlé.
Déjà croire que les GC sont la solution miracle à tous les problèmes d'allocation mémoire, c'est se mettre le doigt dans l'oeil parce qu'un GC n'est jamais parfait. Ensuite, dans certains domaines comme l'embarqué, la consommation mémoire doit être strictement encadrée parce qu'il y en a peu. Et c'est plus souvent ce point qui pousse à utiliser une allocation manuelle que la "performance". Il est montré qu'un GC peut être aussi performant que l'allocation manuelle mais qu'il prend 5 fois plus de mémoire !
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par gasche . Évalué à 5.
Certes, dans le domaine de l'embarqué, les langages à GC actuels ne sont pas de bons outils. Mais ça ne change rien à ce que j'ai dit : les techniques disponibles de gestion automatique de la mémoire en C ou en C++ sont plus lentes que les techniques équivalentes en Java ou en OCaml par exemple. D'ailleurs, l'article que tu as cité le dit lui-même, en première page :
Dans mon message je n'ai fait aucune comparaison de performances entre des mécanismes de gestion de mémoire automatique et de gestion de mémoire manuelle (puisque ce sont deux choses différentes, qui devraient être utilisées pour des usages différents). J'ai comparé la performance des gestionnaires automatiques disponibles dans différents langages. Et j'ai constaté que des langages obsédés par le fait de pouvoir tout contrôler de ce qui se passe au runtime comme le C ou le C++ (obsession bien visible, peut-être à raison, dans le message auquel je réponds), les mécanismes bas niveau introduits pour permettre ce contrôle fin peuvent aussi jouer contre les performances à plus grande échelle, en rendant non sûr des techniques d'implémentation performantes qui seraient possible en leur absence.
Par ailleurs, si on doit vraiment en arriver là, je tiens quand même à préciser que l'article que tu cites ne donne aucun chiffre solide sur la comparaison entre gestion manuelle et gestion automatique de la mémoire. Je ne veux pas dire que les mesures effectuées sont fausses, mais qu'elles mesurent quelque chose qui n'arrive jamais en pratique : on prend un programme avec GC, on le fait tourner pour calculer où peuvent/doivent être libérées les variables, et on insère ensuite magiquement des malloc/free vers un custom allocator ultra optimisé à ces endroits là. L'"arnaque" (qui n'est pas du tout malhonnête, l'auteur ne prétend pas permettre de faire des comparaisons entre C et des langages collectés) c'est que dans un vrai programme à gestion manuelle, le programmeur ne peut pas se permettre en général d'insérer magiquement les malloc à l'endroit optimal. Il utilise des techniques bien connues pour faire du code fiable en présence d'allocation manuelle (des "design patterns" du malloc/free si on veut), comme les RIAA (allocation et destruction suivant la structure lexicale du programme) ou d'autres conventions qui sont uniformes et maintenables, mais du coup plus du tout optimales, et donc utilisent plus de mémoire que l'exemple idéal mesuré dans l'article.
Enfin, avec des systèmes de type plus puissants on peut avoir des systèmes de gestion de mémoire automatique qui n'ont pas besoin de tout allouer sur le tas, et donc d'utiliser un GC aussi souvent. Je t'invite à te renseigner par exemple sur le langage ATS, qui utilise des types linéaires et peut s'en servir pour décider d'allouer sur la pile. Bien qu'utilisant un GC, des comparaisons de performance avec le C te montreront qu'il est globalement aussi rapide, et utilise en général moins de mémoire.
Bien sûr (attention petit troll pour le fun), ça c'est un langage de recherche avec de la vraie innovation dedans, pas du réchauffé comme Go, alors attention, il faut brancher son cerveau.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par ecyrbe . Évalué à 2.
Pour ce qui est des appels via une table (indirection), tu auras beau mesurer dans tous les sens, ce sera toujours plus lent qu'un appel direct dans les cas génériques.
Ensuite, certaines plateformes sont optimisées pour minimiser le cout d'un appel indirect, mais ce cout sera juste dans le meilleurs des cas équivalent au cout d'un appel direct et dans les autres moins bon. Donc jamais meilleurs.
Penser à ce genre de mécanismes (même s'ils sont cachés au programmeur qui n'en ont rien à faire) à son importance dans certains contextes, par exemple pour les langages systèmes. Hors Go vise a devenir un langage système.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par gasche . Évalué à 4.
Ce qu'on fait les gens de Self que j'ai déjà cité précedemment, au tout début des années 90, c'est d'utiliser des techniques d'inlining agressif des méthodes appelées, combinées à du JIT. Du code natif inliné est plus performant qu'un appel direct.
Après, ça ne vient pas gratuitement, il faut tout un mécanisme d'instrumentation pour repérer les méthodes à inliner, le JIT a aussi un coût, etc. Je ne prétends pas que c'est plus rapide dans tous les cas, mais qu'on peut obtenir des performances équivalentes dans le cas général. Par ailleurs, ces optimisations dynamique sont souvent plus efficaces en pratique que les optimisations statiques faites par les compilateurs, puisqu'il y a beaucoup de cas où un raisonnement statique n'est pas possible mais où l'instrumentation donne des prédictions extrêmement précises. Cf. par exemple cet article sur le C++, qui s'inspire du travail fait sur Self : "Reducing Indirect Function Call Overhead In C++ Programs", Brad Calder and Dirk Grunwald, 1994.
Par ailleurs, je crois que tu te fourvoies sur le sens du mot "système" dans "programmation système". Dans la bouche des créateurs de Go, je pense qu'il ne s'agit pas d'écrire le gestionnaire de mémoire d'un noyau d'OS, mais plutôt de toute la partie "userland non graphique" qui se trouve au dessus du noyau. Et qui a plus besoin d'outils fiables qui permettent de programmer de larges systèmes que d'une élimination prédictible des appels indirects.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par gasche . Évalué à 2.
Évidemment, j'ai oublié la citation qui tue de l'article :
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par ecyrbe . Évalué à 4.
Ils concluent à la fin que :
We recommend that compilers for highly pipelined, speculative execution architectures : use profile-based static prediction methods to optimize C++ programs, use link-time information to remove indirect function calls, and customize call-sites using ‘if conversion’ based on profile information
Hors cet article date de 1994. GCC emploi depuis ces techniques et ses dérivées comme les "profile-guided optimisations" (pour les branch prediction et le l'inlining). Donc les compilos c++ actuels emploient déjà ces techniques qui se montrent aussi efficaces que les techniques dynamiques beaucoup plus couteuses en terme d'implémentation et d'overhead dans le runtime.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par gasche . Évalué à 3.
Oui, nous sommes d'accord.
Si j'ai évoqué les méthodes de compilation des langages "très dynamiques" (que ce soit par JIT ou profile-based compilation) c'est pour montrer qu'on peut avoir une sémantique qui semble impliquer des appels indirects, et quand même une implémentation performante derrière, de nature à satisfaire les personnes exigeantes.
Après, ça ne veut pas dire que l'implémentation effective du langage à un instant donné effectue ces efforts d'amélioration des performances. Dans ce sens ta question sur l'implémentation actuelle de Go est tout à fait pertinente. Mais je pense que sans invoquer le spectre du "sufficiently smart compiler" on peut juger que Go a une forte marge de manœuvre là-dessus et qu'il serait dommage de juger le langage (qui est avant tout une sémantique) sur des détails d'implémentation de ce type.
L'inconvénient dans tout ça, c'est la perte de la predictibilité de la copmilation. Plus le compilateur est malin, plus il est difficile pour le programmeur d'être certain de ce qui va se passer. Mais c'est aussi le coût à payer pour une expressivité plus forte (car dans le fond, si on ajoute une indirection ici, ce n'est pas pour le plaisir, c'est parce que ça permet de mieux écrire des programmes).
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par dohzya . Évalué à 1.
Euh… perl a du typage dynamique, donc il n'a pas besoin d'une telle fonctionnalité…
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par lasher . Évalué à 2.
Ce dont tu parles ressemble beaucoup à de l'inférence de type (du genre de ce qu'on trouve dans les langages fonctionnels).
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par gasche . Évalué à 2.
Pour information, le fait que toutes les classes qui ont les bonnes méthodes respectent automatiquement l'interface est ce qu'on appelle précisément le "structural subtyping", par rapport au "nominal subtyping" utilisé dans la plupart des langages OO mainstream. "structural" puisque c'est la structure des objets (l'ensemble des méthodes exposées et de leur type) qui décide la relation de sous-typage, et pas des déclarations explicites et "nominales" au niveau de la déclaration de la classe.
Ce n'est pas exactement nouveau, les différences entre ces deux techniques (qui ont chacun avantages et inconvénients, la structurelle étant généralement considérée comme meilleure mais un peu plus complexe) ont été débattues à mort. Pour donner un exemple, la couche objet de OCaml, apparue au tout tout début des années 2000, utilise le sous-typage structurel.
(Le lien avec les templates C++ est plus que ténu : les templates n'ont pas de rapport avec le sous-typage, et le comportement extrêmement ad-hoc qui permet de le faire croire ici est une conséquence (parmi d'autres) de leur stratégie de compilation par ailleurs extrêmement pénible pour un usage normal.)
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par spider-mario . Évalué à 3.
http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/
Ça s’appelle « typage structurel », c’est disponible dans d’autres langages comme Scala, OCaml et haXe.
C a l’opérateur « , ».
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par monde_de_merde . Évalué à 2.
J'ai essayé le Go (parce que j'avais du temps à perdre un week-end). donc je critique : au delà des changements d'habitudes, je n'ai pas compris ce que ça pourrais m'apporter d'utiliser le Go plutôt qu'autre chose. Du coup j'ai vite fait tout oublié. Même sans parler des qualité intrinsèques du machin, avec tout le respect qu'on peut avoir pour le travail des concepteurs, mais j'ai l'impression que c'est juste une perte de temps d'apprendre à utiliser ce truc.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par djano . Évalué à 1.
Ça a l'air super sympa en effet. Ça doit être pratique quand tu ne peux pas modifier le code d'origine.
Moi ce dont je rêve le plus, c'est de pouvoir vérifier statiquement que ma variable implémente deux interfaces a la fois Je n'ai pas envie qu'elle soit limitée a déclarer une seule interface.
Je ne trouve pas que ce soit mieux qu’écrire:
# Langage Google: non merci !
Posté par Stéphane K. . Évalué à -2.
Rien que pour ça, j'en veux pas: plateforme Google, applications Google, langage Google ... Et puis quoi "-Google" demain ?
Et dire que tous ces Go-go-googlings croient être "modernes" (plus que leurs prédécesseurs en tout cas) : ils participent juste à la construction - bien avancée - du bon vieil "evil empire" à Papa, saveur "-Google".
Qu'est ce qu'Erlang n'avait pas pour lancer Go ? Pourquoi ne pouvait-on pas faire évoluer Erlang ? Parce qu'Erlang n'est pas "Erlang-Google".
Sans moi donc.
[^] # Re: Langage Google: non merci !
Posté par reno . Évalué à 10.
Une syntaxe que les développeurs aime?
[^] # Re: Langage Google: non merci !
Posté par outs . Évalué à 7.
Syntax error: French language implies space before "?"
Syntax error: Agreement between verb "aime" and noun "développeurs" does not fit
^_^
[^] # Re: Langage Google: non merci !
Posté par barmic . Évalué à 1.
:2s/Syntax/Conjugaison/
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Langage Google: non merci !
Posté par cho7 (site web personnel) . Évalué à 2.
franchement erlang c'est du sucre syntaxique super calorique à coté de ce que je vois du Go. Et pourtant j'suis pas du tout branché fonctionnel à la base.
[^] # Re: Langage Google: non merci !
Posté par CrEv (site web personnel) . Évalué à 10.
Faut voir que c'est ptetre du "-google" car google, lui, fourni des équipes, des ressources, etc pour permettre à ce genre de langage d'évoluer, d'exister ?
Je sais bien que c'est pas le seul, que des langages existent en dehors (mais beaucoup ont une fondation, une entreprise, officiellement ou officieusement - par exemple payer le dev principal), mais peut-être est-ce un -google uniquement parce que google a dit "ok, prenez des gars et faites le" ?
On peut critiquer comme on veut google, mais sur ce plan ils ne sont pas trop mauvais quand même (bon, on peut aussi trouver des choses intéressantes chez microsoft research par exemple, mais c'est plus confidentiel et ça n'a pas le même côté 'fun' malheureusement).
Avant que ça troll, microsoft research fait des trucs pas mal, et même certains en open source.
Hum, pas tout à fait d'accord, ne serait-ce que parce que beaucoup de ces choses développées chez google (et pas forcément par google) sont open source. Dans ce sens, ben c'est pas forcément un problème.
[^] # Re: Langage Google: non merci !
Posté par O'neam Anne . Évalué à 2.
D'ailleurs, j'ai même souvenir d'un projet Microsoft Research (en partenariat avec une université suisse, certes) qui ne compilait pas sous Windows, et pour lequel ils recommandaient d'utiliser Debian ou Ubuntu. Ce qui montre bien que Microsoft Research est assez indépendant des divisions plus « commerciales » de Microsoft.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Langage Google: non merci !
Posté par flagos . Évalué à 7.
C'est open-source, ca ne semble pas blinde de brevets, c'est un projet qui a l'air suivi en terme de staff par Google et interessant d'un point de vue technique.
Que te faut-il de plus ?
[^] # Re: Langage Google: non merci !
Posté par barmic . Évalué à 7.
Bouh c'est caca c'est entreprises un peu touche à tout ! Comme si des sociétés comme Sun ou IBM avaient apportées quelque chose à l'informatique.
Ce qu'il faut c'est bien découper les métiers et surtout que personne n'aille voir comment ça se passe chez le voisin.
L'expérimentation c'est la mort de l'informatique !!!
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Langage Google: non merci !
Posté par gasche . Évalué à 2.
J'aime bien quand tu mets le point d'ironie.
[^] # Re: Langage Google: non merci !
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Erlang avec un langage pour les êtres humains:
http://reia-lang.org/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Langage Google: non merci !
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Il y a aussi https://github.com/josevalim/elixir
# Tordu ?
Posté par Firwen (site web personnel) . Évalué à 5.
Je dois être le seul tordu à trouver Go sympa.
Pour du dev Web, des petits softs clients ou du script, il a la rapidité d'un langage compilé avec une bonne partie de la souplesse d'un langage interprété
[^] # Re: Tordu ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Malheureusement, c'est encore un langage intéressant sans débugger, ni IDE...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tordu ?
Posté par Sebastien Binet . Évalué à 1.
on peut utiliser gdb pour deboguer, sans trop de probleme...
[^] # Re: Tordu ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Sans trop de problème, ça veut dire avec à peine l'affichage la ligne courante? Ou avec un support complet pour afficher les variables, les goroutines, etc..?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tordu ?
Posté par zaurus (site web personnel) . Évalué à 1.
Dans gdb: Cx-a pour voir plus qu'une ligne. ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.