Qui utilise Golang ?

Bonjour, je souhaiterais savoir quelle entreprise ou quel développeur utilise ou se lance sur le développement en Golang.org ?

Pour ma part après réflexion je trouve ce langage très impressionnant notamment pour le développement backend (serveur applicatif). Il possède également un framework web MVC http://revel.github.io meme si cela m’intéresse moins.
Il y a de plus en plus de startup qui migre du code vers ce langage avec des retours impressionnants en terme de performance pour des ressources matérielles moindres. Voir ce slide http://decouvrir-golang.net/presentations/slideshow-introduction-a-google-go.html#/

1 J'aime

Docker, le projet open-source le plus actif au monde, est également codé en Go.

Selon moi, c’est une excellente alternative à C/C++, mais comme je n’utilise pas ces langages, je n’utilise pas non plus Go et je ne pense pas migrer de si tôt.

Je pense que ce n’est pas seulement une alternative à C/C++ mais aussi python et ruby. http://www.iron.io était codé en ruby avant de passer à Go : http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html passer de 30 serveurs à 2 ca vaut le coup … :smile:

Après c’est une solution pour l’instant backend, mais il est possible que revel puisse dominer les framework en java, ruby, python : plus simple que les javaries et plus performants que les langages scripts.

1 J'aime

Un billet présente 9 arguments en faveur de Go :
http://java.dzone.com/articles/9-things-i-about-go

1 J'aime

J’ai fait quelques projets en Golang, mes collègues aussi. Nos retours concordent :

  • temps d’apprentissage très court
  • le langage n’apporte rien de particulier (corollaire du point précédent)
  • la gestion des dépendances pose problème pour la maintenabilité
3 J'aime

merci Clément pour ta réponse, concernant le dernier point il me semblait justement que Golang simplifiait la gestion des dépendances, peux tu en dire plus ?

C’est optimisé pour la simplicité au début : tu fais un import from github directement dans le code source, un go get plus tard, c’est bon, tu as ta lib.

Le problème c’est que ce pattern vieillit très mal (la master d’un dépôt ça bouge au cours du temps, voire le dépôt peut disparaitre). Du coup tu te retrouves à DL toutes tes dépendances à la main et à les coller manuellement dans ton gopath.

A une époque, j’avais suivit le développement d’un jeux sur Kickstarter qui a fini dans les choux principalement à cause du téléchargement automatique d’une dépendance qui se faisait, allez savoir pourquoi, toujours sur la branche « main » alors que l’équipe de dev du jeux utilisait une version un peut plus ancienne (mais incompatible avec la nouvelle release). Du coup, les participants n’arrivaient pas à compiler et lancer le jeux => Le projet a fini dans les oubliettes au bout d’un an.

Sinon, pour dir du bien aussi, il y a eut plusieurs annonces de contributeurs sur d’autres projets (nodeJS par exemple, vu que c’est ma partie : http://thenewstack.io/another-respected-developer-says-farewell-to-node-js-and-hello-to-go/) qui ont préféré Go à leur langage fétiche.

Le truc, c’est que pour se passer d’un Ruby On Rails et basculer vers Go, ça va me sembler un peut hasardeux. Surtout que les langages de Script tels que Ruby (et Python) offrent quelques avantages d’architecture bien pratique, mais ont vraiment un gros retard par rapport aux Go Routines.

Ludo.

@clementd => Gaps ! J’ai vu ton message juste après avoir posté le mien. Sais tu s’il est possible de modifier ce fonctionnement pour faire pointer une dépendance vers une version précise sur GitHub ? On peut le télécharger n’importe quelle version avec n’importe quel outil, mais Go semble utiliser toujours le dépôt « main » :frowning:

Il y a toujours la possibilité sur Github de forker des projets et maintenir ta propre version basée sur une branche du projet source, ce qui simplifie alors la maintenance (faire régulièrement des push/pull/tests). Par contre ça fait bricolage.

Oui @Zarmakuizz, j’ai vu qu’on avait proposé de faire comme ça à son dev de l’époque. Le truc, c’est que le problème n’avait pas du tout été anticipé et comme toujours quand un projet démarre très (trop) vite, il n’y a pas forcément de filet. Mais tu as raison, ça peut être la solution au problème histoire de ne pas avoir la surprise que son code ne compile plus chez les autres alors qu’il compile très bien chez soi :slight_smile:

1 J'aime

Sinon, pour répondre un peut plus à la question, Docker est écrit en GO, et il est de plus en plus utilisé pour faciliter le déploiement d’applis en environnement virtualisé (ou pas d’ailleurs) : https://docker.com/

Bonjour Fredix,

Pour ma part, ma future société d’édition de logiciels utilisera pleinement GO côté serveur.

Je vais écrire des choses que tu sais déjà, mais je ne dis pas cela pour toi mais pour la communauté du site.

Je pense que c’est un environnement encore jeune mais sérieux et qui va avoir un bel avenir. Il lui faut encore des années avant qu’il séduise en masse mais aux USA il est utilisé en silence car cela fonctionne sans histoire…

Actuellement les porteurs de « package » sont souvent des codeurs de Google et qui jettent les bases de fondations solides.

C’est idéal pour réaliser des exécutables autonomes embarquant middleware sgbd, serveur http pour API, et ce pour Windows, OS X & Linux depuis une distribution Ubuntu de développement.

GO est très intéressant pour les anciens codeurs C.
Plusieurs points de GO me font penser à ADA.
La programmation est pragmatique (c’est idéal pour des codeurs quarantenaires) . Certes, on ne fait pas de la programmation objet avec, mais on peut concevoir avec une « logique » objet suffisante.

Sans troller, ce n’est pas un « écosystème » pour vendre des jours de prestations en mode SSII. C’est un bon environnement pour réaliser des plateformes robustes et qui doivent pouvoir monter en charge sans mouliner comme des dingues.
En effet, pour les serveurs hautes performances (de production pas théorique), c’est une tuerie du fait de la conception même du language - A lire dans la FAQ http://golang.org/doc/faq#csp - :
"
Why build concurrency on the ideas of CSP?

Why goroutines instead of threads?
"

2 J'aime

Pour ceux qui suivent l’actualité : Adoption de GO-Lang sur Android pour accéder à une partie des API C natives du NDK (principalement pour les besoin graphiques des jeux) et le reste via un binding Java. L’info ici : http://www.infoq.com/news/2014/06/golang-google-android-native-dev

1 J'aime

Je pense en être également.
Principalement pour utiliser des outils existants dans ce langage (docker, etc) et quelque frameworks qui me tentent. Mais à voir à l’usage si je reste avec ça, ou j’accepte de perdre des cycles CPU (pleins ? :p) avec du ruby et/ou python.
En tout cas, pas de java pour moi, je le trouve tellement verbeux globalement.

1 J'aime
Proposé avec ❤ ️par Camille Roux