woffer 🐧 a écrit 176 commentaires

i pi, i copi just ski change, boujou ché té

Hey, les futurs webmester de redoxfr.org, n'oubliez pas d'y accoler GNU (GNU/Redox.org), sinon RMS ne voudra pas venir faire une interview !!!

Stricto sensu non. Manjaro a des versions. Ces versions ne sont pas majeures mais elle a quand même des versions, contrairement à Arch Linux qui n'a pas de version.

En Go, le pattern c'est de retourner (resultat, erreur). Si tu ne verifies pas l'erreur, dommage le compilateur ne t'aidera pas à t'en rendre compte.

Tu peux utiliser des linters et notamment le metalinter golangci-lint qui fait référence et évitera ce genre d'erreur (entre autres).

En plus il faut toujours gérer 4 cas: (result, nil), (result, err), (nil, err), (nill, nil). Et si les cas 2 et 4 semble improbables et inutiles, il n'y a pas besoin de chercher très loin dans la doc de la lib standard pour trouver des exemples (read par exemple, qui peut retourner des données et un EOF).

Euh, non pas spécialement, si tu retournes la valeur et non son pointeur donc (résultat, erreur) et pas (*résultat, erreur), tu ne peux pas avoir tes deux derniers cas (nil, err) et (nil, nil). Car tu disposeras directement de la valeur qui ne peut être nulle.
Après plus de 6 années d'expérience intensive de programmation en Go, mes fonctions ne retournent pratiquement que des valeurs donc (result,error). Si je dois retourner un pointeur, c'est qu'il y a un besoin bien particulier comme retourner une structure avec un partage d'un espace mémoire (ex : mutex et co).

Si j'ai bien compris, tu mets un point de restauration à la première utilisation et tu le restaure au bout de 90 jours, c'est bien ça ?
Du coup, quel est l'intérêt de Microsoft de fournir ce genre d'image ?

Pour streamer du JSON like, tu peux utiliser du JSONL, c'est très pratique pour échanger des données entre back-end car facilement streamable. Si la performance est vraiment problématique pour les échanges entre back-end, tu peux te tourner vers des formats binaires avec schéma (protobuf, … ) ou sans schéma (msgpack, …).

De la même manière Discord bascule de Go à Rust pour son écosystème de bibliothèques notamment en matière d’asynchronisme avec Tokio (EN), sa gestion mémoire et ses performances globales.

Visiblement, la comparaison ne semblait pas très juste car basée sur une vieille version de Go (cf. le tweet du leader technique de Go Russ Cox https://twitter.com/_rsc/status/1224802726774812672?s=20).

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.