woffer a écrit 69 commentaires

Il me semble peut-être à tort que Google utilise le concept des micro kernel pour son Fuchsia OS.

Moi, j'en ai eu au moins 1 sur une trentaine de visages demandés.

Les runners de gitlab ci sont écrits en Go. Donc, j'imagine que ça ne doit pas prendre beaucoup de RAM.

Hello,
Quelqu'un a-t-il déjà essayé drone?

Pourquoi ne pas sortir du lot en proposant des compétences plus rares mais utiles ? Je pense notamment au Go qui peut être utilisé dans pour le développement dans différents domaines comme le devops ou le backend.

Bonne question merci.
Il faut utiliser le principe du fan-in fan-out qui permet de paralléliser N requêtes et les merger voir annuler celles qui restent si une échoue. Go montre toute sa puissance ici.

Je suis complètement en accord avec toi sauf malheureusement quand les librairies n'utilisent pas Netty ou d'autres (e.g. Apache Mina). Dans mes précédents développements (je travaille pour un grand telco français), nous devions nous interconnecter avec une plateforme d'accès gérant plusieurs millions de clients. Nous utilisions un client radius en Java qui n'utilisait pas les nio. Donc, nous étions obligés de configurer nos pools de threads pour ne pas dégrader la QoS de notre plate-forme avec des pools de threads vidés car le serveur radius était par moment un peu long à répondre…

Alors qu'en Go, l'asynchronisme (via epoll sous linux) est obligatoire car géré par le runtime de façon transparente.

De plus, comme je l'ai déjà dit, je préfère que le code soit écrit en synchrone qu'en asynchrone car beaucoup plus simple maintenir par la suite surtout par quelqu'un d'autre.

C'est justement l'intérêt de Go, qui contrairement à Java par exemple, ne bloque pas les threads systèmes sur les entrées/sorties réseaux. C'est pour cela que Go propose que des clients synchrones d'un point de vue des goroutines dans son SDK.

Je peux te dire que venant du monde Java backend, cela a toujours été l'horreur de configurer la taille des pool de threads (souvent fait au doigt mouillé) d'autant plus quand tu accèdes à des API qui répondent plus moins vite (donc bloquant plus ou moins les threads).

J'aime le Go et son semblant d'aspect synchone car il me permet de lire le code comme un livre. C'est dire naturellement.

Oui sans aucun doute ;)
Disons que c'est plus un partage d'expérience :p

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