Le langage Go de Google est disponible en version finale depuis 2012. Il a depuis évolué à travers plusieurs nouvelles versions, et l’éditeur vient de lancer la mouture 1.5. Elle reste évidemment compatible avec les précédentes mais apporte bon nombre de nouveautés.
Go est un langage développé par Google et qui vise essentiellement la programmation système. Il est largement inspiré du C et du Pascal et a pour objectif de produire du code natif particulièrement rapide à exécuter. Il peut bien entendu être utilisé pour le développement des logiciels, et l’exemple le plus représentatif est d’ailleurs Docker, la solution de référence pour les conteneurs logiciels.
La nouvelle version 1.5 du langage est disponible depuis hier. Elle apporte de nombreuses améliorations, parmi lesquelles certaines sont particulièrement importantes. Elle vise particulièrement les optimisations pour les processeurs possédant plusieurs cœurs. Le parallélisme des instructions est ainsi favorisé et le développeur n’a plus à préciser quel nombre il souhaite en utiliser dans son application : par défaut, ils sont tous utilisés (du moins tant qu’il y a des tâches à accomplir).
Tout aussi important, le langage Go se débarrasse de ses dernières fondations en C et mange sa « propre nourriture ». Le compilateur n’est ainsi plus écrit en C mais en Go 1.5, ce qui permet un meilleur travail du ramasse-miettes (ou récupérateur de mémoire). Ce dernier évolue d’ailleurs pour devenir concurrentiel (le travail s’exécute depuis un autre cœur ou processeur). Des améliorations de performances sont présentes, Google indiquant que les pauses passent d’une fourchette de 1 à 2 secondes, à un temps compris entre 10 et 20 millisecondes sur un programme de 10 Go.
Autre ajout important : des ponts vers C et C++. Depuis une application créée avec l’un de ces langages, Go peut être appelé sous forme d’une bibliothèque. Cette capacité a été ajoutée pour faire de Go un environnement capable de servir de NDK (Native Development Kit). Google garde évidemment Android en mémoire, d’autant que les architectures ARM64 pour Darwin et Linux sont supportées, ouvrant également les portes d’iOS.
En clair, l’éditeur espère faire de Go la plateforme de développement à tout faire, réduisant pour les développeurs le besoin de recouvrir à un trop grand nombre de langages différents. Un créneau déjà assez concurrentiel, avec notamment Xamarin pour faire le lien vers l’environnement .NET.
Ceux qui souhaitent récupérer la dernière version du langage Go pourront le faire depuis le site officiel. Les développeurs qui veulent jeter un œil sur la version mobile se rendront pour leur part sur le dépôt Github consacré à ce projet.
Commentaires (82)
#1
le sous titre mdr
#2
Doit-on comprendre par le sous-titre que le langage Go est un gadget ?
" />
Ah, c’est une référence à l’inspecteur gadget ?
#3
Go est déjà intégrable à des applis Android ? Quelqu’un ici l’a déjà fait ? Et qu’est-ce que ça donne ?
#4
Posons la questions de manière plus générale. Est-ce que quelqu’un ici a déjà utilisé Go?
#5
Je crois que je l’avais téléchargé et je m’étais arrêté là, en bon codeur que je suis ^^’
#6
Oui :) et il est vraiment plaisant. Les performances sont top, les librairies, la doc et la communauté sont tops. J’ai dev quelques webservices avec et c’est du bonheur
#7
Quels avantages à utilise Go plutôt qu’un C# par exemple?
#8
J’ai un collègue qui utilise go pour beaucoup d’outils qu’il dev sur le côté, ou pour l’aider, là où la plupart d’entre nous passent plus volontier par python ou ruby.
A priori il en est content ^^ Il faudrait que je regarde…
#9
Google Go home !
#10
C# c’est comme java => tu as besoin d’une machine virtuel sur lequel le code tourne
C# c’est officiellement que pour Windows… (oui il existe mono pour faire tourner son code C# ailleurs, mais ceci n’est pas proposé directement par l’equipe C# )
donc en gros C# ca a les inconveniants de java, sans l’avantage (ton code tourne partout peut importe ton OS)
Go c’est comme C ou C++ => ca tourne directement sur la machine, donc forcement deja plus rapide
par contre c’est compilé pour TON os… tu ne peux donc pas donner ton binaire a quelqu’un sous linux…
#11
A quoi sert le Garbage Collector dans ce cas ?
#12
#13
C’est faux pour C#. Le .Net est officiellement sous Linux depuis début d’année. Toute la partie Core.
Pour l’installer sur Ubuntu : https://dotnet.readthedocs.org/en/latest/getting-started/installing-core-linux.html
Et je ne ferais pas comparaison Java & .Net… ça va troller.
#14
La syntaxe reste toujours moins sexy que du ruby :p
#15
#16
Est-ce qu’au moins c’est facile de faire de compiler pour un autre OS? Parce que une ou deux fois j’avais dû compiler du C pour windows (sans avoir de windows), qu’est-ce que j’en avais chié pour trouver les instructions pour le faire…
#17
Je donnerais juste un avantage (amha) de C# sur Java.
L’ensemble des bibliothèques utilisées me parait un peu plus homogène, là ou l’écosystème Java te donne un embarras de choix de bibliothèques différentes articulées autour des même spécifications (API)… mais pas toujours compatibles si tu choisi les mauvaises. (mauvaise expérience où l’on m’a laissé en roue libre)
Après avoir beaucoup de choix c’est aussi une très grande force, mais pour le coup je préfère quelque-chose d’homogène et cohérent sans avoir à me casser la tête sur la compatibilité éventuelle.
On pourrait aussi parler d’écritures du langage (comme les expressions lambda), simples et puissantes du C# que le Java n’a pas, ou a seulement depuis peu, de l’intégration dans les produits MS (Office, Windows…) vs portabilité multi OS de Java.
Les deux langages ont leur place.
Tout comme les langages orientés système comme C, C++, D et Go ont leur place.
#18
Petite question de mémoire : comment les dev font pour retenir toutes les fonctions et les subtilités de chaque langage ? Perso, je n’ai jamais été bien attiré par la prog et quand j’essaie de m’y plonger et que je vois tout ce qui a à retenir, ça me décourage. Comment on fait pour ne pas tout mélanger ?
" /> Déjà que même avec les CMS faut souvent bidouiller pour avoir le résultat qu’on veut…
Une fois j’ai été obligé d’écrire un bout de code php, ben je me suis arraché les cheveux pour un truc de 10 lignes qui fait un truc ultra basique : aller lire une ligne dans un ficher de log et réécrire le résultat.
Bref, c’est pas demain la veille que je développerais un site web de zéro
#19
En pratiquant principalement.
" />
Et bien sûr: Google et StackOverflow
Après c’est pas pour rien que beaucoup de dev ont soit fait ça pendant des centaines d’heures sur leur temps perso, soit ont carrément fait des écoles (d’ingénieurs ou université) où on t’apprends à coder.
Après le développement web et applicatif sont deux aspects bien différents. Personnellement je suis incapable de faire un site web potable, mais je suis plus qu’honnête en Java, et quand j’en faisais encore, j’étais pas mauvais non plus en C.
#20
Ba chaque langage est articulé plus ou moins par les même concept (boucle, condition, fonction etc..), chose que l’on apprend en faisant de l’algorithmique (certains décide de passer directement a la pratique avant le théorie, c’est le coté obscure!).
Une foi ces concepts maîtrisé y a plus qu’a se tourné vers les doc pour apprendre les API en fonction de nos besoin (au début on passe notre temps a faire de la recopie en se faisant aider par l’auto complète, puis avec le temps sa viens tous seul).
Idéalement on commence par des truc tous con (pour se faire la main) avant de se lancer dans des vrais projet.
#21
va jeter un oeil à du Erlang et tu verras que Go à une syntaxe très sexy finalement… :)
Franchement la syntaxe n’est pas si affreuse en Go. L’utilisation de channel par contre peut paraître très abstraite au début mais ça marche bien !
#22
En pratiquant et comme dit renaud07 y’a une certaine logique que l’on retrouve quasi partout.
J’ai ralenti mais à une époque je passais pas mal de temps chez moi en plus du boulot à apprendre de nouveaux langage, nouvelle techno etc…
Mais bon perso je me vois de moins en moins faire ça toute ma vie.
#23
Donc c’est comme tout en fait, faut pratiquer longtemps. Et si on est pas attiré par le truc à la base c’est un peu compliqué…
#24
Si on devait comparer Go à un autre langage ce serait plutôt Rust: des langages proches de C/C++, orientés performances (quoique encore en deçà de C/C++) mais également orientés déploiement (une des “philosophies” de Go étant le packaging monolithique, l’appli Go contient en elle-même toutes ses dépendances, pas de library externe). Il en résulte moins de soucis de dépendances, mais des livrables plus encombrants.
Par contre ce qui est moche dans Go, c’est que tous les concepts modernes passent à la trappe, en ce qui concerne la programmation fonctionnelle. Tout ce que peuvent apporter des langages comme Scala / Haskell / Java 8 (streams) etc. De ce point de vue, Go est très “old school”.
#25
#26
+1 le mieux c’est encore de te donner un objectif/projet, et de t’y lancer.
" />
" />
Perso, c’est comme ça que j’ai fait ma première app Android
Bon le code est dégueulasse, et il faudrait que je refasse tout de zero, mais au moins maintenant je peux dire que j’ai des notions de code Android
#27
“En clair, l’éditeur espère faire de Go la plateforme de développement à
tout faire, réduisant pour les développeurs le besoin de recouvrir à un
trop grand nombre de langages différents. Un créneau déjà assez
concurrentiel, avec notamment Xamarin pour faire le lien vers
l’environnement .NET.”
Je dirais qu’au contraire, en faisant des ponts vers C/C++ Google encourage la fragmentation: il s’adresse aux développeurs qui maintiennent une appli legacy C/C++ et qui souhaitent évoluer en douceur vers un langage plus moderne sans devoir tout réécrire en one-shot.
#28
j’ai cru comprendre que coder pour android avec java est une galère. Pour ma part, je suis parti dans la direction kivy pour faire mon app. Et pour coder, ça va super vite.
#29
Perso, je ne saurait juger n’ayant pas vraiment testé autre chose 
" />
#30
Go est tout simplement fantastique et il est en train de devenir le langage de référence pour le cloud et le devops. Ça commence à percer aussi dans le web quand on a besoin de beaucoup de vitesse et de concurrency.
#31
T’as plus d’infos ? Je fais ça quotidiennement depuis 6 ans et je n’y vois aucune galère, du coup ça m’intéresse le ressenti que peut avoir un débutant sur la plateforme/langage.
#32
Hein ?
Je n’ai jamais codé pour android, je ne vois pas trop en quoi Java pour android soit plus difficile que du Java classique “Swing” avec un code “propre” MVC, plein de trigger&co
#33
#34
je ne blâme pas le language en soi, mais ce que j’ai cru comprendre de négatif concerne les outils de développement.
#35
Ok en effet les multiples versions et résolutions sont un vrai casse-tête, je confirme, mais on s’y fait.
" />
Et Android Studio a effectivement réglé pas mal de problèmes. Il n’est malheureusement toujours pas au niveau d’un Visual Studio mais c’est en bonne voie
#36
Oui enfin là ça en revient à me demander si je préfère avoir dans les mains de la bouse de cheval ou de chameau :p
#37
Qu’est ce que tu entends par langage de référence pour le cloud ?
Pour les devops, j’en vois bcp qui aime le langage pour le déploiement (c’est clair que move un binary reste bien plus simple que le reste XD). Mais en soit les outils les plus puissants reste dans des languages tiers il me semble (ruby et python entre autre)
Faut juste faire attention à ne pas tomber trop vite dedans dans le sens où pour recruter dans une boite une personen ayant déjà fait du Go c’est pas forcement ce qu’il y a des plus facile (On peut toujours former vous me direz, oui, mais ça a un coup aussi)
#38
#39
la on est d’accord, mais c’est moins moche que du C ou du java
#40
Les outils évoluent vite. Ils ne sont peut être pas au niveau de ceux sur iOS (encore que ça fait longtemps que je n’ai pas regardé ce qui se passait du côté de la pomme), mais ils sont déjà très bons. Il existe tout un tas de vérifications de code faites à la volée, ça permet d’éviter les erreurs les plus basiques.
#41
Merci pour Kivy je ne connaissais pas (et pourtant j’en ai cherché des solutions cross-platforme open source ^^), je testerais des que je peux.
Concernant Java et Android c’est loin d’être galère, il y à certaines petites choses qui sont pas évidentes à faire (surtout concernant les styles, par exemple changer la couleur de l’action bar ou des tabs d’un pager), mais à part ces quelques éléments qui nécessites de tricker le reste c’est du bonheur.
Je crois même que c’est la techno sur laquelle j’ai eu le plus de facilité à rentrer.
#42
#43
Je code dans ce langage depuis un an maintenant, c’est un réel plaisir. Relativement performant mais surtout très rapide en temps de dev. On est pas encore au niveau du python à ce niveau, mais niveau perf quelle différence.
#44
Go est un langage qui combine beaucoup d’atouts des autres. Sa simplicité et son efficacité sont vraiment très agréables. J’adore sa gestion des erreurs (même si je sais que tout le monde n’adhère pas). Le mot clé “defer” est un pur bonheur, le système de goroutines aussi, la manière dont les objets sont gérés …
Pour info (et pour répondre à certaines questions) :
#45
@nekogami
En fait justement ça fait plus de 10 ans que je ne fais que du .Net. Que ce soit client lourd ou web.
Mais pour le web, le monde Microsoft (surtout les développeurs .Net) sont complètement loin de la réalité et ne sont que des suiveurs. Quand Microsoft sort un produit (par exemple asp mvc) ils ont déjà du retard et en plus, le temps que les devs s’y mettent, la techno est devenue presque obsolète ! Ça m’a tellement dégouté que j’ai commencé à chercher autres choses et Go est sorti du lot. Là je viens de trouver un job où je ferai que ça.
Quelques avantages :
- Sa vitesse.
- Un framework assez solide fourni avec et une communauté géniale.
- Un GC et donc permet un développement plus rapide.
- En terme de concurrency et threading, jamais vu plus souple et plus pratique que les goroutines.
- La cross compilation natif. Par exemple générer un binaire linux tout en étant sur windows.
- Une compilation très rapide.
Les défauts :
- Pas encore de debugger.
- Assez rebutant quand on vient d’un monde orienté objet.
#46
Ah pour le web, t’inquiète pas, je supporte pas asp non plus XD.
Maintenant, linq par exemple, j’ai toujours pas trouvé plus sympa a utiliser perso.
Ça ou, la syntaxe pour tout ce qui est execution asynch en .NET 4.5 que je préfère à la syntax go routine (je la trouve sympa, c’est juste une préférence perso).
Sinon t’inquiète pas que je suis d’accord par rapport aux avantages / défaut de Golang hein.
#47
#48
goroutines et async/await n’ont presque rien en commun en fait.
Pour mieux comprendre je conseille fortement ses slides : http://talks.golang.org/2012/waza.slide
Linq, complètement d’accord :) Même s’il y a beaucoup de haterz (Souvent parce qu’ils savent pas l’utiliser proprement), c’est la meilleure chose qui est arrivée à C# et n’a pas d’équivalent dans d’autres langages.
#49
Merci pour les renseignements
" />
#50
Personnellement je ne vois aucun intérêt à faire du asp sur linux.
Pour le moment CoreCLR reste de la poudre aux yeux …
Seul avantage, c’est qu’on pourra déployer indépendamment du framework. Uniquement utile pour les besoins internes à MS pour Azure je dirais lol
Si c’était WPF, ce serait en effet une autre histoire …
#51
#52
Go compile en assembleur et fait de l’allocation dynamique avec ramasse miette ?
#53
Tout comme le font de nombreux framework en C++.
#54
#55
#56
Oui, MS travail sur le portage de WPF en .Net Native(c’est à dire la possibilité de se passer de la machine virtuel .Net et de l’installation de son framework), qui permettra d’en gros faire comme du Go (ou du C++, techniquement c’est la même chose).
Et non, Gooom, CLRCore n’est pas de la poudre aux yeux, c’est une étape vers le .Net Native et la portativité. Ce n’est pas une fin en soit, c’est un moyen.
De même pour ASP.Net, la version 5 est une réarchitecture complète (et recodage d’une grosse partie) on peut espérer que ça remette cette techno dans la course, car elle se traine effectivement de vieux problèmes… Normalement on devrait en avoir une première version exploitable en Novembre (pour WPF c’est repoussé à 2016).
#57
je m’avancerais pas trop sur le winform ou wpf sur les autres platformes je t’avoue, ptètre les universals apps (via xamarin pour les api system ? ) histoire de booster le développement. Puis ils sont en train de voir pour le .net native sur les autres platformes aussi, via llvm :)
#58
Les postes clients lourds sont encore très largement en Windows, donc ils seraient en effet étonnant qu’ils allouent du budget sur la portabilité de WPF/WinForms.
Pour les client légers, où Android tient la corde (85% ? quelque chose comme ça…), ils ont l’air de s’en remettre à Xamarin. Je les vois pas concurrencer Xamarin tout de suite, ils semblent plutot coopérer (tant que aider Xamarin permettra d’arriver à la compatibilité .Net sur Android à un cout moindre que de le faire en interne, je pense qu’ils resteront sur cette solution).
Il n’y a que sur les serveurs Web où les solutions Unix/Linux sont présentes sans avoir de réponse, d’où le portage IIS/ASP.Net et services sur Linux.
Par contre .Net Native risque fort de se généraliser, ça à l’air de marcher comme ils veulent sur leur UWP (Win10) donc ils vont pouvoir enchainer si les language natif continuent à leur mettre la pression (et ça semble être la direction prise par tout le monde).
#59
Je trouve cette réponse assez juste :http://stackoverflow.com/a/7480033
Je rajouterais aussi que l’autre différence à ne pas négliger est tout simplement la vitesse d’exécution et le nombre donc le cas d’utilisation et l’utilité.
Sinon avez vous un lien officiel concernant WPF ?!!
WPF me parait impossible mais UWP est probable …
@darkdestiny
Ce débat est trop long et chiant pour ici :p
Quant au linux, ça n’a aucun intérêt car tu dois te couper de tout l’écosystème MS et avoir des IT unix dans une culture 100% MS … donc lol :p
#60
Attention, CoreCLR et .Net Native sont des chantiers différents qui n’ont pas les mêmes buts (et qui sont orthogonaux).
CoreCLR est bien d’avoir une CLR qui s’exécute sur plusieurs plateformes (mais c’est toujours de l’IL avec compilation JIT).
.Net Native qui est expérimental depuis WP8 (ou 7.5 je ne sais plus) a pour but de se passer de l’installation du redistribuable .NET (et a fortiori plus de compilation JIT). Résultat, chaque appli embarquera son coreclr et mscorlib dans son exe. C’est “simplement” une étape de plus à la compilation : on prend les assemblies .net en MSIL, on n’enlève ce qui ne sert pas (tree-shaking) et on compiler en binaire.
Ce qui est complexe avec .Net native c’est l’étape de tree-shaking : comment savoir quel type est utilisé et lequel ne l’est pas. Sur un Framework comme CoreCLR ou le .Net embarqué pour les apps universelles, le périmètres est petit et la réflexion plutôt limitée. Pour remédier à ce problème, des “hints” peuvent être mis en place pour préciser quoi garder. Se posent aussi des cas plus complexes de réflexion et l’utilisation de la DLR (via dynamic par exemple).
#61
Le CoreCLR n’est pas qu’un problème de CLR, mais surtout de dépendance (framework + tiers). Et le fait que les applications embarquent l’intégralité de ce dont elles ont besoin (implémentation spécifique à la plateforme + CLR portable + dépendances portable) est précisément la base utilisé pour généré l’assembleur (il serait très compliqué de faire du tree-shaking sur les 5 ou 6 implémentations actuelles de la CLR et surtout des dépendances, non seulement pour MS mais aussi pour les devs qui devraient tester chacune d’elles au final !).
Pour .Net Native, ce n’est plus expérimental, c’est passé en “release” le même jour que Windows 10: http://blogs.msdn.com/b/dotnet/archive/2015/07/30/universal-windows-apps-in-net.aspx
Plus d’infos: http://blogs.windows.com/buildingapps/2015/08/20/net-native-what-it-means-for-universal-windows-platform-uwp-developers/
#62
C’était un post du blog .Net sur la roadmap .Net, et l’auteur du post (un PM .Net) avait répondu dans les coms que le cas WPF était l’objectif de départ de .Net Native, puisque c’est le cas où le temps de démarrage (où l’absence de JIT peut faire le jour et la nuit) est le plus source de mécontentement (la faute à une mauvaise interop bien souvent…). Le .Net Native sur UWP n’est là encore qu’une étape pour arriver ensuite à WPF (qui est bien sur largement plus compliqué car plus souple, mais c’est la même techno).
Mais pour des raisons politiques, priorité a été mit sur la portabilité d’asp.net 5 (ça tient à cœur à Satya et consor), donc tant que c’est pas fait (et on verra pas la version final avant 2016) ils ne bosseront pas vraiment sur WPF (les équipes MS étant en vases communicants) donc on aura pas de date de sitôt malheureusement… En tout cas pas avant la BUILD 2016 m’est d’avis.
#63
D’accord, Go c’est bien. Mais avais-t-on vraiment besoin d’un autre langage c-like ?
Faut bien avouer qu’on n’en manque pas de langages c-like. Alors pourquoi celui là ?
La richesse de l’écosystème de développement ? La multitude de librairies prêtes à l’emploi ? L’intégration parfaite avec l’OS/Runtime ? Le volume de tutos/exemples disponibles sur le web ? La bonne connaissance du langage chez tous les étudiants/développeurs/SSII ? J’ai un doute.
C’est un bon langage. Mais… ce n’est pas le seul. Et je ne vois pas pourquoi le choisir dans le cas des “cœurs multiples” et du “développement mobile”.
#64
#65
C’est pour cela que j’ai dit que les deux (async/await et goroutines) n’ont presque rien en commun et ils ne sont pas vraiment comparables. Peut-être je me suis mal exprimé. Les deux font très bien leur boulot mais pas du tout dans le même objectif et utilité.
Pour le HFT justement j’entends de plus en plus des migrations vers Go. J’ai d’ailleurs eu une offre pour. Go simplifie énormément la programmation concurrentielle car c’est fait pour.
L’autre point important aussi ce sont les ressources allouées. J’ai vu dans pas mal de blog qu’en réécrivant leur appli en Go ils ont par exemple diminué carrément leurs serveurs de 10 à 2. Et encore les serveurs s’ennuyaient.
C’est vraiment pas une question d’aimer ou ne pas aimer. J’adore toujours C#/.Net et j’y ai investi énormément du temps. Mais quand tu veux faire du web/concurrency/system, C# n’est pas fait pour ni la politique dominatrice de MS.
#66
#67
Pousse ton raisonnement plus loin. Avec le C 11, pourquoi utiliser un C-like et pas directement le C?
#68
J’ai l’impression d’avoir dérivé le débat par rapport à la news, je commence à regretter d’avoir rebondi sur le C# moi … XD.
Sinon en ce qui concerne ces adopteurs de Go, ouai y’a pas mal de truc qu’on peut trouver sur le net par rapport à ça c’est assez fou.
C’est surtout qu’après la période de buzz de NodeJS (grosso modo, c’était les même articles), je préfère voir ce que ça donne sur la longueur au niveau cohérence du code et comment ça va vieillir.
C’est mon plus gros problème avec GO pour le moment.
Aussi, je n’y retrouve pas la simplicité de debug et de compréhension du code que j’ai en ruby.
(Ça et le fait qu’aujourd’hui front/back ne sont pas correctement séparée).
#69
NodeJs n’est pas prêt de s’arrêter et c’est en train même de prendre plus de l’ampleur avec Isomorphic JavaScript. Des libs comme Meteor ou React par exemple et dans Angular 2 on en parle aussi.
Franchement quand tu vois qu’il y a Ken Thompson ou Google derrière le projet Go c’est assez rassurant. Mais la durée de vie d’une techno est vraiment dépendante de sa communauté …
Sinon je te l’accorde c’est un langage encore jeune et pas sans risque ! Il faut pas y aller tête baissée. Il y a eu un jeu sur Steam (ou je sais plus où) en Go par exemple qui s’est cassé les dents …
#70
#71
#72
” Google indiquant que les pauses passent d’une fourchette de 1 à 2 secondes, à un temps compris entre 10 et 20 millisecondes sur un programme de 10 Go.”
" />
??? C’est quoi un programme de 10 Go ? La taille disque de l’exécutable ? Je sait bien que de nos jour, on se moque de ça, mais quand même. Dire que de mon temps, les démomaker faisait de super truc en 256octets, tournant sur des machines avec 640Ko de mémoire.
#73
L’article m’a bien fait rire XD.
" />
Plus sérieusement, ne pas utiliser RVM ou tout autre gestionnaire de version ruby est casse gueule. Ça fait partie des truc cool et chiants à la fois.
Ensuite, l’écriture de son gemfile est diront nous, à revoir.
Quand tu spécifie pas tes version de gemfile, vaut mieux juste bundle et non bundle install.
Mais j’ai quand même ris
#74
#75
#76
#77
C’est Kickstarter je me suis trompé. Le voici :
" />
 https://www.kickstarter.com/projects/2066438441/haunts-the-manse-macabre
 http://www.bbc.com/news/technology-20003916
C’était il y a 3 ans.
PS: Avec “Controller as” on peut se passer complètement de $scope
#78
J’utilise déjà
" />, y’a quand même certain truc quand tu fais des directive avec scope isolé où tu va passer par du scope. (binding au travers d’attribute etc etc).
Pub/sub d’evênement qui passe par le $scope (en soit j’aurai pu le faire un JS pure, mais bon, ça rend bizarre)
#79
Pour faire court, pourquoi à l’époque php a écrasé asp.net et la majorité des gens l’ont adopté ?! D’un coté la politique de MS et de l’autre parce que webforms est juste une abomination. Un frankenstein pour ceux qui connaissent rien au web. Pendant 7 ans avant l’arrivé ultra tardif de asp mvc, ça a changé la culture des développeurs web .net et les a rendus à coté de la plaque. De nos jour c’est ultra difficile de pouvoir recruter un bon dev .net qui sache coder 2 lignes de Js correctement, ou qui connait le protocol http ou la notion de concurrency et de montée en charge :(
" />
Oui MS se défend mais ce n’est qu’un suiveur et non un apporteur d’innovation. Il a toujours une dizaine de trains de retard dans le Web.
Pour la culture ce n’est pas full Ms ou full Linux, c’est full Ms ou full multi culture
#80
Heu tu veux dire démo 4k parcque 256 Octets tu ne rentres pas grand chose :)
Et je pense que c’est 10Go de mémoire vive
Edit: ah ben si y’avais bien des démos 256 octets.. punaise j’avais jamais connu et pourtant j’ai du faire ma première démo partie en 97-98
#81
Cool, les déploiements vers 1.5 commencent et c’est déjà impressionnant niveau GC :
 https://goo.gl/gzvt9C
#82