woffer 🐧 a écrit 210 commentaires

En relisant, je m'aperçois que je n'ai pas fermé le body de la réponse. Donc voici la version corrigée :

package main

import (
    "encoding/xml"
    "log"
    "net/http"
)

type totozes struct {
    Name []string `xml:"totoz>name"`
}

func main() {
    res, err := http.Get("https://totoz.eu/search.xml?terms=plop")
    if err != nil {
        log.Fatal(err)
    }
    defer res.Body.Close()

    if expected, actual := http.StatusOK, res.StatusCode; expected != actual {
        log.Fatalf("unexpected status code [actual: %v] [expected: %v]", actual, expected)
    }

    var (
        d         = xml.NewDecoder(res.Body)
        totozList totozes
    )

    if err := d.Decode(&totozList); err != nil {
        log.Fatal(err)
    }

    for _, Name := range totozList.Name {
        log.Println(Name)
    }
}

Hello,
Pour moi, le Go est dans son élément ici. Les goroutines vous permettent de ne pas vous occuper de l'aspect asynchrone/synchrone.
Go c'est une application qui tourne avec 10 à 20 Mo d'emprunte mémoire, qui se comporte très bien sur un pod k8s dont les ressources sont inférieures 100 millicore, qui démarre quasi-instantanément, dont le déploiement est simplissime un simple binaire dans un container from scratch, dont la taille sera de quelques mega (ici 6.1Mo pour binaire linux amd64).

Le tout avec un langage qui reste simple (pour des cas simples), très bien outillé (vet, race …), génial pour la concurrence, la gestion des timeouts/fin de vie (via les context) et qui va utiliser tous les cores disponibles de façon optimale.

Bref, qu'en pensez vous ?

https://play.golang.org/p/ElZ99l4WTd-

package main

import (
    "encoding/xml"
    "log"
    "net/http"
)

type totozes struct {
    Name []string `xml:"totoz>name"`
}

func main() {
    res, err := http.Get("https://totoz.eu/search.xml?terms=plop")
    if err != nil {
        log.Fatal(err)
    }

    if expected, actual := http.StatusOK, res.StatusCode; expected != actual {
        log.Fatalf("unexpected status code [actual: %v] [expected: %v]", actual, expected)
    }

    var (
        d         = xml.NewDecoder(res.Body)
        totozList totozes
    )

    if err := d.Decode(&totozList); err != nil {
        log.Fatal(err)
    }

    for _, Name := range totozList.Name {
        log.Println(Name)
    }
}

Oh mince alors, il nous reste Debian 😁

Pour avoir utiliser les deux (dep et mod). Et bien, je suis contant que Russ ait imposé la vision de la gestion des dépendance qui beaucoup plus simple et suffisamment puissant.

C'est aussi un outil qui va nettoyer les logiciels qui adoptent des mauvais comportements (je pense à toi k8s qui change son API sur chaque nouvelle version mineure) car ils devront enfin respecter la gestion sémantique

C'est exactement le même ressenti que j'ai. Moi, je n'ai jamais eu de problème avec cette distribution. Elle est très bien fournie grâce Arch tout en limitant les mise à jour, une grosse maj une fois toutes les deux ou trois semaines.

Je ne dirai pas ça, j'aime Arch car elle permet de comprendre un peu plus en profondeur Linux. J'aime aussi Arch pour la possibilité de tuning. Elle m'a permis d'installer une Arch Linux sur une clef USB et de tuner le système pour limiter les écriture sur la clef USB en passant tout les écritures en RAM puis lors de l'arrêt du système synchroniser avec rsync. Et surtout j'aime Arch pour la très grande qualité de son wiki.
Donc, Arch c'est bien, mais Manjaro aussi ;)

J'ai suivi leur wiki à la lettre, et je n'ai jamais installé sur mon Arch des paquets provenant de Manjaro.
Non, les problèmes que j'ai eu ont toujours été des problèmes mineurs mais c'est agaçant. Le dernier en date, si je me souviens bien, a été un problème de certificat lors de la mise à jour. Ce sont des problèmes mineurs mais je n'ai jamais eu ça avec Manjaro.

J'utilise les deux et franchement j'ai plus de problèmes avec Archlinux que Manjaro. Mais bon, à mes yeux ce sont de très bonnes distributions. Ce que
j'aime quand même dans Manjaro, c'est ça simplicité d'installation par rapport à Archlinux (c'est quand même brute de décoffrage ;)) et surtout beaucoup moins de mise à jour. Sur Archlinux, j'en ai plusieurs fois par jour, alors que Manjaro les regroupe en une seule.
Ça évite les mise à jour du logiciel version x.y.z-1, puis une nouvelle mise à jour du même logiciel en version x.y.z-2.

Personnellement, j'utilise Manjaro comme poste de développement professionnel depuis plusieurs années et c'est stable. J'ai beaucoup moins de problèmes que j'avais avec Fedora lors des montées de version. Bref, je recommande chaudement. C'est une Archlinux (que j'utilise sur ma machine perso) avec beaucoup moins de mise à jour.

Le vol de travail par exemple est un modèle un peu plus récent

Ce mécanisme est aussi implémenté dans le runtime de Go. En effet, les M goroutines sont réparties sur N threads (un thread par core de la machine) avec un M en général beaucoup plus important N (c'est le principe du scheduler M:N). Le principe du vol de travail (c'est à dire des goroutines en attentes) est mise en œuvre entre les différents threads dans le runtime de Go cf. https://rakyll.org/scheduler/

Il y a un outil pour détecter les race conditions en Go, race detector, mais je ne le trouve pas très efficace.

Juste pour compléter, l'outil race detector est basé sur de la détection des accès concurrents non protégés qui se produisent lors des tests unitaires lancés avec le mode race ou sur une des instances en production qui a été compilée avec le mode race. Les erreurs sont sorties sur l'erreur standard, elles donnent les goroutines incriminées en écriture (voire en lecture) et la zone mémoire (variable, tableau…).
Il n'analyse pas le code source pour trouver les accès concurrents non protégés (pas d'analyse statistique). Il ne permet pas de garantir que le code est sûr s'il ne détecte rien par contre s'il détecte une erreur c'est vraiment un accès concurrent non protégé qu'il faudra corriger. Il n'est donc pas parfait mais il a le mérite d'exister.
Pour moi, le couple benchmark ou test unitaire avec plusieurs appels en parallèle (par exemple pour une API WS plusieurs requêtes jouées lors des tests unitaires) et le mode race activé fonctionne très bien. Il me donne une bonne garantie que le code est sûr d'un point de vue des accès concurrences non protégés et il est exécuté dans la CI sur chaque push.

Et surtout c'est une très bonne couche d'abstraction. Pour le OPS, que tu (en tant que DEV) produises une image légère ou un peu plus grosse (ex: jvm + ton appli) pour l'OPS ç'est un peu près la même chose. Les OPS peuvent in fine facilement l'installé sur un cluster k8s.

Pour moi, le couple From scratch + Go est parfait. L'image fait quelques mo, l'empreinte mémoire est d'une vingtaine de mo. Et même si on attribue quelques millicores au pod, le serveur Web de Go se comporte très bien. Bref, je suis satisfait.

Ok, awk est très puissant.
Par contre, si je souhaite parser des gros fichiers avec le minimum de ressources ou le plus rapidement possible, alors je préfère utiliser grep+cut pour sa sobriété et rapidité.

D'où ma question, j'ai cherché aussi et pour fois je n'ai rien trouvé même pas dans AUR. Donc, j'ai (ou on a) sans doute loupé quelque chose.

Hello,
La configuration de la variable d'environnement GOPATH n'est plus nécessaire depuis go 1.8.
Si elle n'est pas configurée, alors la valeur ${HOME}/go est utilisée.
https://github.com/golang/go/issues/17262

Hello,
Savez-vous s'il existe un package pacman de disponible pour Arch Linux ?
Merci

Voici le genre de problème que cette évolution doit corriger :
https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns/

Je l'utilise au boulot et Manjaro stable fonctionne sans aucun souci.

Non, mais la remarque porte plus sur le YAML en général que sur la modification des playbooks via vi.

Plus sérieusement, un truc que je trouve vraiment sympa, et qui n'est pas possible avec cette approche, c'est l'indentation automatique à chaque sauvegarde du fichier, comme c'est l'usage en go avec gofmt.

Je n'ai pas osé aborder le sujet de Go avec gofmt (et goimports) car après je suis intarissable.
Ce langage est, de mon point de vue (back-end), une véritable tuerie <troll>largement meilleur que le couple Java/Spring Boot</troll>.
C'est un sujet assez chaud au sein de mon équipe.

Oui, c'est toujours l'histoire du temporaire qui dure ;)
Mais après c'est un choix des équipes/projet.

Merci pour l'info.
Malgré tout, il n'est pas toujours possible d'installer ce que l'on souhaite sur des environnements de production (e.g. conteneur Docker)

À part python, qui est justement le language dans lequel est écrit ansible ;-)

Effectivement, quand j'ai écrit ça je me suis dit que j'avais un peu trop généralisé et que je m'exposais à un retour de bâton rapide de la part lecteurs de linuxfr aux yeux impitoyables ;)

Moi, j'utilise principalement Intellij IDEA et le plugin Ansible.
Il t'apporte un peu d'aide mais il y a encore des manques (notamment au niveau des templates Jinja2).