Bruno Michel a écrit 3285 commentaires

Pourquoi tu n'enrobes pas cette logique dans un readable ?

Tu parles des readable streams ? C'est déjà le cas dans l'exemple ci-dessus (fs.createReadableStream crée bien un readable stream) et dans cozy-desktop. C'est juste que pour cozy-desktop, il y a plus d'étapes dans le async.waterfall et l'étape pour créer le readable stream comporte un if pour choisir si on le crée depuis un fichier local ou une URL distante.

Tu pourrais réduire un peu toute cette complexité avec le async.

C'est-à-dire ? J'ai utilisé le module async dans l'exemple. Ou tu parles de async/await ? Async/await n'est pas supporté pas node 6.

Je peux utiliser :

process.on('uncaughtException', (err) => {
  console.log(err.stack);
});

mais ça ne change rien, ça affiche toujours :

Error on source { Error: ENOENT: no such file or directory, open '.npmignore'
    at Error (native) errno: -2, code: 'ENOENT', syscall: 'open', path: '.npmignore' }

Pour le on('close') vs on('finish'), les deux donnent le même résultat ici. Ils ont une légère différence de signification, mais ce n'est pas important ici. Pour cozy-desktop, la sémantique de finish me convenait mieux.

Bon, par contre, pour les stack traces, il y a encore des progrès à faire. J'ai rencontré un bug sur cozy-desktop, le futur logiciel de synchronisation entre son ordinateur personnel et son cloud personnel. Et je peux vous dire qu'avoir une stack trace qui ne fait référence à aucun fichier du projet, ça n'aide pas à débugger.

Pour reproduire, il suffit de prendre ce bout de code simplifié :

// err.js
const async  = require('async')
const fs     = require('fs')
const stream = require('stream')

let source

async.waterfall([
  (next) => {
    const stream = fs.createReadStream('.npmignore')
    next(null, stream)
  },
  (stream, next) => {
    source = stream
    source.on('error', (err) => {
      console.log('Error on source', err)
    })
    const target = fs.createWriteStream('.npmignore.old')
    next(null, target)
  },
  (target, next) => {
    target.on('error', (err) => {
      console.log('Error on target', err)
    })
    source.pipe(target)
    target.on('finish', next)
  }
], (err) => {
  console.log('Done', err)
})

et de le lancer :

$ node -v
v6.1.0
$ npm init
$ npm install async
$ node err.js
Error on source { Error: ENOENT: no such file or directory, open '.npmignore'
    at Error (native) errno: -2, code: 'ENOENT', syscall: 'open', path: '.npmignore' }

Alors, ici, le code paraît bizarre parce que j'ai essayé de reproduire l'exemple de cozy-desktop en le simplifiant beaucoup. Dans cozy-desktop, quand on ajoute un fichier en local qui vient du serveur cozy, on fait d'autres étapes comme s'assurer que le répertoire dans lequel on va écrire le fichier existe. La création du stream source est également plus compliqué : si on a déjà une copie du fichier en local, on va utiliser cette copie, sinon on va passer par le réseau pour récupérer le fichier depuis le serveur. Etc.

La version 6.0.0 est pour node.js. Node.js 5 utilisait le moteur V8 en version 4.6 et Node.js 6.0.0 est passé à V8 en version 5.0, ce qui a permis une meilleure prise en charge d'ES6.

Le "The Computer Language Benchmarks Game" offrent des versions optimisées dans différents langages à des problèmes donnés. Et pour ces problèmes donnés, je le trouve personnellement trés bons et effectivement une "référence en terme d'optimisation". Mais peut-être ai-je tord ?

Ce benchmark a pas mal de défauts :

• Déjà les versions dites « optimisées » ne le sont pas toujours. Dans certains langages, il y a eu effectivement pas mal de temps passé pour optimiser le problème. Dans d'autres langages, c'est juste la première version qui a marché qui est testée, personne n'a cherché à optimiser.

• Les langages n'implémentent pas tous les mêmes problèmes. Certains langages n'ont pas des implémentations pour tous les problèmes ou des versions trop anciennes qui ne compilent plus.

• Les benchmarks sont très faussés vers une utilisation pure du CPU (absence total d'I/O). Et seulement 4 cœurs, ça paraît peu de nos jours (mon PC qui a quelques années en a 8).

• Les règles pour les benchmarks m'ont l'air floues. J'ai l'impression que certains langages profitent de bindings vers un langage plus bas niveau (genre le C++ qui utilisent des trucs en C plutôt que leurs équivalents en C++). D'autres langages ont l'air de précalculer à la compilation (qui n'est pas prise en compte dans les comparaisons), ce qui n'est pas possible pour les langages dynamiques.

Donc, tous les exemples Meteor-React sont en ES6, mais, pour apprendre React, les tuto du site React sont en ES5, même si l'équipe même de React conseille d'utiliser ES6.

Facebook, qui développe React, a embauché le développeur de babel il y a quelques temps. Donc, ce n'est pas étonnant qu'ils poussent pour ES6 (babel fait de la transpilation ES6, 7 et + vers ES5).

Sinon, on commence à voir la montée en puissance de TypeScript, et dans une moindre mesure de Flow. Ces 2 outils servent à ajouter du typage statique. Est-ce que c'est quelque chose que l'on voit aussi dans la communauté Meteor ?

Oui, sur le blog de V8 : http://v8project.blogspot.fr/2016/04/es6-es7-and-beyond.html et les premiers commentaires sur Hacker News : https://news.ycombinator.com/item?id=11598245.

Je n'ai pas dit que ça doit résoudre tous les problèmes. Mais je pense qu'il n'y a pas d'incompatibilité en général entre l'utilisation d'un Garbage Collector et l'embarqué. Il faut juste un GC qui convient. Celui d'Erlang qui convient dans pas mal de cas. Azul est une autre solution.

Sauf que tous les workloads ne sont pas partitionables

Les workloads qui ne sont pas partitionnables, ça reste une cas très spécifique.

Un autre argument contre les garbage collectors donne par Linus est la perte de localite de reference: lorsque le GC decide de faire une collection, tu te retrouves avec un cache pollue par les objets collectes.

Je ne vois pas trop ce que cet argument vient faire ici. Oui, la fragmentation de la mémoire est un problème, pour les GC comme pour la gestion de la mémoire manuelle. En l'occurrence, l'utilisation de fibres/goroutines/processus Erlang aide justement pas mal.

D'une part, quand un processus Erlang finit, sa stack et sa heap sont entièrement supprimées. Et c'est de cette façon qu'une bonne partie de la mémoire est libérée. D'autre part, le GC est générationnel : il recopie les objets récents encore utilisés de l'espace réservé aux objets nouvellement créés vers un autre espace. Ainsi, il y a peu de "trous" et on évite une partie de la fragmentation de la mémoire.

Ca dépend vraiment des contraintes : si par exemple tu vises des latences inférieures à la ms ça va être très dur avec un GC dès que la taille du tas devient conséquente

Il suffit de ne pas avoir un seul tas avec une taille conséquente mais de répartir les données. C'est ce qu'Erlang fait avec ses processus (qui sont différents des processus de l'OS) ou Go avec ses goroutines. Pour Erlang, ça permet de lancer le GC sur un processus Erlang sans bloquer les autres processus et sur un espace mémoire très petit, donc ça va vite.

Erlang est utilisé pour des switchs et pour l'infrastructure des réseaux mobile (GPRS, 3G, LTE). Autant dire, Les latences inférieurs à la ms ne font lui pas peur.

Python n'utilise pas de garbage collector mais un compteur de référence, tout comme Swift et PHP.

C'est un avis pour le moins surprenant. Le compteur de référence n'est qu'un élément. Python a bien des pauses pendant la libération des anciens objets qui ne sont plus utilisés. Peux-tu détailler pourquoi tu ne considères pas ça comme un Garbage Collector ?

Si ce coût est acceptable pour des services de petite et moyenne taille, il l'est beaucoup moins quand on parle de jeux videos, de 3D, d'application système lourde, de calcul scientifique ou simplement de systèmes embarqués.

A priori, Julia s'en sort bien pour le calcul scientifique. Et Erlang a plus que fait ses preuves pour les systèmes embarqués.

Effectivement, ça dépend de la définition de "proche". Pour moi, 10 à 20 % plus lent que le C/C++, ça reste proche.

Tous les langages dynamiques (JavaScript, Ruby, Python, PHP, etc.) sont 10 à 100 fois plus lent que le C. Go et Scala sont 2 à 3 fois plus lent que le C.

Comme ça, je dirais qu'un langage a des performances proche du C si on parle de son écart de performances en pourcentage et non en nombre de fois plus lent.

Ça se discute : Java a des performances proches du C. Ocaml est également connu pour ses performances proches du C et utilise aussi un GC.

Le Garbage Collector utilisé est celui de Boehm-Demers-Weiser.

Cf https://linuxfr.org/sections/administration-systeme

Cf https://github.com/linuxfrorg/linuxfr.org/commit/229b2f1931df611a36c7c0b952a98c79cb6115bd

Quel serait l'intérêt d'un telle option ?

Ça pose pas mal de des problèmes et personne n'a trop l'air d'en vouloir (l'entrée de suivi a un score de -3 en ce moment) => je ferme.

pas sûr qu'il utilise toujours Ruby non ?

J'utilise encore un peu Ruby, mais plus beaucoup, et LinuxFr.org est le seul bout de code en Rails dont je m'occupe encore. Ceci dit, Ruby reste le langage dans lequel je me sens le plus à l'aise et le plus productif aujourd'hui. C'est juste que professionnellement, je n'ai pas trop le choix, c'est JavaScript à fond (heureusement que le projet en vaut le coup), et sur mon temps libre, j'aime bien essayer d'autres langages et façons de faire (Elixir et Elm notamment).

Bruno donnera volontiers le coup de main pour ne pas rester bloqué dans les méandres de Ror

Oui, pas de soucis, je peux aider s'il y a un point de blocage.

Des micro-services en Go ?

Il y a déjà img et epub et ça n'a pas l'air de passionner les foules non plus.

Je suis persuadé que Bruno ne manque pas d'idée de ce genre

Personnellement, c'est l'espace de rédaction collaboratif que j'aimerais bien refaire. Je voudrais un truc vraiment temps réel où les gens peuvent inter-agir plus facilement (on oublie les verrous à l'édition d'un paragraphe), tout en gardant la notion d'historique et la possibilité de savoir qui a fait quoi. Un mélange d'etherpad et git.

Peut être https://docs.docker.com/linux/step_one/

Un contributeur a déjà ajouté un dockerfile pour pouvoir installer une instance locale avec docker, justement pour faciliter les contributions. Depuis, je ne pense pas que ça ait servi à qui que ce soit (en tout cas, je n'ai eu aucun retour).

Du coup, mettre en place un serveur bac à sable, ça me paraît être beaucoup de boulot pour pas grand chose. C'est loin d'être simple à mettre en place, et le temps que ça prendrait à l'équipe de faire ça pourrait être bien mieux utilisé pour d'autres choses.

On aurait probablement intérêt à fournir un générateur de contenus à coup de lorem ipsum

Une autre possibilité serait de prendre le flux Atom du site et de créer les contenus correspondants dans le site local via un script. Ça ne devrait pas être très dur à coder. Faut juste que quelqu'un se motive à le faire.

Toutefois la multiplication de préfixes propriétaires semble bel et bien terminée car deux des principaux navigateurs, Chromium et Firefox, n’utiliseront plus cette technique pour introduire de nouvelles directives CSS.

Il semblerait que Webkit aussi n'introduira plus de nouveaux préfixes : https://webkit.org/blog/6131/updating-our-prefixing-policy/

Je n'ai pas encore eu le temps de lire, mais il semble y avoir pas mal d'infos sur les packages snap par ici : http://blog.labix.org/

Bah, le bricoleur avec un seul tourne-vis, je doute qu'il soit très bon. Je ne suis qu'un bricoleur du dimanche mais je sais qu'il y a un paquet de vis de tailles et formes différentes et qu'un seul tourne-vis, ça ne le fait pas.

Mais passons outre cette analogie, la question est de savoir si on devient un meilleur développeur en se concentrant sur un seul langage ou si aller voir ailleurs peut aussi être efficace. Dans le commentaire initial, le meilleur développeur est celui qui est le plus rapide à réaliser une tâche donnée. Je trouve cela très réducteur, il faudrait au moins prendre en compte d'autres aspects comme la maintenabilité, la sécurité ou les performances du programme en question. Mais rien que pour la rapidité, je pense qu'il est préférable de connaître plusieurs langages.

Dans la courbe d'apprentissage, au début, il est effectivement préférable de se concentrer sur un seul langage. Mais une fois arrivé à un certain niveau, apprendre de nouveaux langages (même superficiellement) permet de voir de nouvelles choses et d'autres manières de faire. Et souvent, il est possible d’incorporer ces nouveautés dans son langage favori pour devenir plus productif. Je suis persuadé que tous les excellents développeurs dans un langage connaissent d'autres langages et se sont servis des enseignements dans ces autres langages pour parfaire leur maîtrise dans leur langage de prédilection.

Tous les développeurs les plus connus maîtrisent un paquet de langages en plus de leur langage de prédilection, sans exception. Bram Moolenaar a écrit Vim, mais a aussi développé son propre langage de programmation, Zimbu. Voici ce qu'il dit sur la page inspiration :

There are many existing programming languages to learn from. All of them have at least a few good ideas. But once you start using them for more than a small program, you also find disadvantages. The trick is to use the nice parts and avoid the bad parts.

Un autre point important est que l'on est très rarement un bon développeur seul dans son coin. Le plus souvent, un bon développeur travaille en équipe et connaître d'autres langages permet de mieux communiquer avec le reste de l'équipe. Un développeur back-end qui connaît un peu d'HTML / CSS / JS sera souvent plus efficace dans son travail que celui qui s'est concentré sur sa partie.

Oui, je me rends compte a posteriori que je n'ai pas mis l'accent où il fallait pour cet article sur Elm. Je voulais garder un article assez court pour ne pas faire peur et permettre à beaucoup de gens de le lire rapidement. Il y a plein d'autres choses intéressantes dans Elm et je ne voulais pas répéter bêtement The Elm Architecture. Bref, peut-être qu'un lecteur proposera une suite à mon article pour le compléter.