woffer 🐧 a écrit 236 commentaires

j’ai l’impression que ça n’est plus le cas

Est-ce que tu penses que ça peut être encore dans la marge de l'effet placebo ?

… j'arrive toujours à commiter

 git commit -m "je suis trop fort, mouaahhh"
 [master (commit racine) 061c379] je suis trop fort, mouaahhh
 1 file changed, 1 insertion(+)
 create mode 100644 maitre_du_monde.txt

Ok, je sors.

une blague est cachée dans cette phrase, sauras-tu la retrouver ?

Non, je n'ai pas su. Je suis nul à ce genre de jeu, par contre je suis curieux.

Par contre le look est clairement marqué années 2000 (voire 90), c'est un peu dommage, mais pas rédhibitoire pour un logiciel de gestion.

Le code aussi, j'ai ouvert et refermé de suite…

Pour Go, je ne suis pas sûr que perf soit le plus adapté (un peu comme gdb ne permet pas d'avoir un debug optimal pour le Go. Il faut mieux utiliser delve).

Tu as torT, voilà, c'est justifié.

C'est un peu torDue comme justification, non ?

Pour pasBill pasGates, il faut mieux dire :
Genre Steve Ballmer ?

Dans quel cas de figure un serveur de base de données serait exposé depuis internet ?

Dans l'optique de participer à l'attaque de SQL Slammer peut-être ? Je reconnais, dans ce cas, que c'est un peu contradictoire à la sécurisation de SQL Server…

Moi, j'aime beaucoup utiliser l'AsciiDoc pour ce genre de tâches (e.g. documentations techniques, présentations) qui se gère très bien dans de la gestion de conf (git et consort), avec des pipelines pour générer dans différents formats.

Le contributeur principal de Redox ne s'appelle-t-il pas Lennart Poettering ? Ou alors c'est qu'il a dû changer de nom pour éviter de nouveaux contrats de tueurs à gage.

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.