GuieA_7 a écrit 689 commentaires

Merci mais je ne vois pas ce que les GC viennent faire ici. Le but d'un GC, c'est principalement d'apporter de la simplicité, pas forcément de la memory-safety.

Vu qu'on se sert principalement de langages à GC pour faire des services Web par exemple (Java/Python/PHP/Go…) et que la sécurité y est un élément important je dirai qu'on embrasse les différentes qualités qu'apporte un GC en général (même si les développeurs ne s'en rendent pas compte car ce sont des problèmes bas niveau). En fait la simplicité vient justement en partie du fait que des problèmes de memory safety n'existent pas. Donc la simplicité ce n'est pas seulement qu'on n'a pas besoin d'appeler free().

ça ne vaccine pas des refontes pour corriger des problèmes mémoires

En ce qui me concerne j'ai déjà corrigé ici-même des gens qui disaient que Rust empêchaient toutes sortes de fuite mémoire. Ici par exemple, dans une dépêche Rust: https://linuxfr.org/news/rust-a-5-ans-retrospective#comment-1823413

Reste que ce n'est pas parce que ce n'est pas une solution miracle qui garantit qu'il n'y aura jamais besoin de "refontes pour corriger des problèmes mémoires" que ça ne veut pas dire que ça ne fait pas mieux que les autres langages (par exemple en faisant que ce genre de refonte est rare—rappelons que l'on parle d'un noyau qui est plus complexe qu'un programme lambda—nul miracle certes, mais un progrès quand même).

Comme je l'ai dit précédemment tu as des avantages des langages à GC (sécurité mémoire + on ne se préoccupe que rarement de libérer la mémoire à la main) mais sans le coup à l'exécution d'un GC (comme dans les langages à gestion manuelle de la mémoire). Oui c'est moins sympa que l'image "ça corrige tous les problèmes mémoire" (ce qu'aucun langage même lent et haut niveau ne peut faire), mais c'est déjà pas mal.

Alors ce n'est pas tout à fait ce que tu demandes, mais j'avais lu cet article intéressant où l'auteur, fan de Kotlin, explique comment il a fini par trouver Rust aussi productif pour les projets complexes: https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/

C'est une question complexe, et il faut commencer par se demander ce qu'on mesure. Exemple (avec des chiffres pipo): si un programme est développé en C en un 1 mois (avec des bugs critiques et complexes à corriger: mémoire, threads…), qu'un programme équivalent est fait en 2 mois en Rust (mais avec seulement 1% des bugs de la version C), et qu'il faudra au final 2 mois supplémentaires à la version C pour corriger les bugs les plus gros (sans atteindre la qualité du programme en Rust) ; alors que peut-on en conclure sur la productivité ? La réponse peut dépendre des cas, si on parle de time-to-market par exemple (et oui même si dans mon exemple là j'aimerais répondre simplement "Rust" pour des raisons de long termes, on sait bien qu'en pratique c'est plus compliqué).

Comme dit plus haut, même les langages à Garbage Collector ne garantissent pas l'absence de fuites mémoire. Ce qui est garanti, c'est l'absence de data race, de double free, de dangling pointers … ; et en pratique il y a beaucoup moins de travail pour le programmeur afin d'éviter les fuites mémoire (99% du travail est fait automatiquement par le GC).

Rust apporte la même chose, à la compilation, sans GC.

Ça permet de faire des petits jeux GameBoy (qui pourront donc tourner dans un émulateur ou une vrai console) dans le style de Pokemon (il semble que la prochaine version pourra permettre de faire des jeux plus variés—shoot'em up etc…):

https://chrismaltby.itch.io/gb-studio

La programmation se fait avec un langage graphique assez simple (et donc limité), les décors peuvent se faire avec Tiled par exemple (GB-Studio prend directement des PNG et retrouve les tuiles lui-même).
C'est plus limité que ce que tu demandes mais peut-être que pour un tout premier jeu ça pourra le faire.

As-tu pensé à mettre ta magnifique prose sous une licence CC (une libre évidemment), ou est-ce que tu penses que ça va te fermer le monde de l'édition professionnelle ?

l'envie de laisser tomber a été renforcée par le peu de contributeurs, peut-être parce que peu de gens ont envie de s'investir dans des maths, et ceux qui ont envie n'ont pas envie de les implémenter et de débugger.

Si ça peut te rassurer (bon, pas sûr) c'est le cas d'une grande partie des logiciels libres d'être portés par une équipe (parfois d'une seule personne) sans grosse contribution externe (même s'ils ont des utilisateurs). Les logiciels comme Linux, pour qui gérer les contributions externes est complexe tellement elles sont nombreuses, sont l'exception et pas la règle.

Bon courage !!

Je vois ce que tu veux dire, mais je ne vois pas trop l'intérêt de faire ta propre définition, d'autant qu'il y a globalement consensus.

Si tu discutes avec des gens qui connaissent les concepts de typage fort/faible et statique/dynamique, il y a toutes les chances qu'ils connaissent les inconvénients du typage dynamique (on ne va pas faire du code hyper critique avec). Ça permet des combinaisons pour rapidement catégoriser les langages, genre le C qui a un typage statique mais plutôt faible (surtout si on ne demande pas au compilateur d'être un peu agressif) ou le Python qui a un typage fort mais dynamique.

Python est un langage faiblement typé et qui a tendance justement à caster implicitement quand il peut […]

Faux. Alors, certes quand la limite entre typage dynamique et statique est assez claire, on ne peut pas juste classer les langages dans les 2 catégories "typage fort" & "typage faible". On a des typages plus ou moins fort. Mais en général le typage de Python est considéré comme fort ; essaie de faire [1, 2] + (3, 4) ou bien 1 + '1' pour t'en convaincre.

En revanche le typage de PHP (à moins que ça ait changé depuis 15 ans) ou de JavaScript est considéré comme faible.

Définir clairement ce qu'est une personne libre est quelque chose de compliqué, qui occupe les philosophes depuis des milliers d'années ; mais on voit quand même à peu près de quoi on parle.

En revanche pour un logiciel ou bien un film, ça ne veut rien dire à la base ; c'est pour ça qu'une définition claire a du être faite dans les années 80.

Du coup partir de la définition du Larousse pour faire une définition à votre sauce c'est très discutable comme pratique. Pour le coup je peux dire que je suis libre d'aller acheter le dernier Pixar en DVD, libre de le regarder autant de fois que je veux, et même libre de le prêter à mes amis. Et donc je peux dire que le dernier Pixar est libre selon moi.

bref si quelqu'un a une explication ?

À mon avis c'est notamment parce que globalement les 2 langages sont très proches (libres & communautaires, portables/multi-plateformes, interprétés, langages impératifs orientés objet, typage fort et dynamique, gestion automatique de la mémoire, polyvalents, expressifs/concis, assez lents…), mais Python est plus vieux et a donc l'avantage d'une communauté plus grosse à la base (et du coup plus de bibliothèques, de tutoriels…). Et donc au moment de choisir un de ces 2 cousins, on part naturellement vers le plus populaire (et qui du coup reste le plus populaire).

C'est un motif qu'on retrouve un peu tout le temps ; 2 solutions techniquement très proches dont une prend l'avantage "réseau" à un moment pour une raison ou une autre, et qui finit par éclipser l'autre (ex: FreeBSD qui propose dans l'ensemble quelque chose de proche d'une distribution Linux, mais à l'époque des déboires juridiques des *BSD, Linux est passé devant).

Ça fait quelques années que sur Twitch le lag n'est que d'une poignée de secondes ; auparavant oui c'était quelque chose comme 20 secondes, et ça rendait les échanges avec le streamer plus pénibles (ex: le streamer va poser une question, mais le temps que la réponse arrive des questions sont posées dans l'autre sens etc… ce qui demande une certaine gymnastique mentale, surtout que le streamer fait souvent autre chose en même temps). Et si j'ai bien compris d'autres plateformes (HitBox?) avaient des latences faibles bien avant Twitch.

Ceci-dit je suis plutôt enthousiasmé que PeerTube s'attaque à ça, j'ai hâte de voir ce que ça va donner.

nouveau concept de « synchronisation d’arguments » dans la classe GimpProcedure afin que les arguments de procédures se synchronisent avec un parasite d’image du même nom ;

paramètre ? (ou sinon je n'ai pas compris de quoi il s'agit).

Si ça fait des années que tu utilises Linux et que tu en es satisfaite, bravo tu as déjà fait ta transition ! Si aucune application propriétaire ne te retient sous Windows alors le dual-boot sera probablement inutile (il finira oublié dans un coin, tu ne te souviendra même plus du mot de passe).

Tu n'as jamais installé toute seule, alors normal que ça te semble mystérieux et complexe, mais aujourd'hui installer une distribution grand public comme Ubuntu ce n'est vraiment pas compliqué la plupart du temps. Le plus difficile c'est de lancer une commande pour faire une clé USB d'installation (et encore je crois que des outils font ça en graphique) et d'aller dans la configuration de ton PC pour lui dire de démarrer sur l'USB. Après tu réponds à 4 questions triviales (langue, nom, mot de passe, pays) et tout se fait tout seul.

Cependant je te conseillerai d'avoir un 2ème PC fonctionnel en parallèle (si tu dois refaire une autre clé avec un autre système parce que la 1ère ne passe pas par exemple etc…). Et comme conseillé au dessus, au moins pour ta 1ère fois le faire dans un LUG (ou avec un(e) ami(e) linuxien(ne)) ; du coup tu n'as pas à fournir l'autre PC fonctionnel évidemment. Ça sera moins de stress, la technique c'est toujours énervant quand ça ne marche pas.

Bon courage pour la suite !

Bref, ce sujet est dans ma liste des sujets dont j’espère pouvoir faire un article

J'ai hâte <3

Ce genre de demake est vraiment très intéressant à voir.
Merci du partage !

Si je comprends bien il y aurait un orateur, et les participants peuvent uniquement l'entendre lors du déroulement de la séance, mais pas le voir ?

Du coup est-ce qu'une solution telle que suivant est acceptable :

1. L'orateur uploade sa présentation sur la plateforme de broadcasting pour sozi, il obtient alors une interface sommaire de pilotage, et un lien unique à donner aux participants (ainsi personne n'a besoin de créer de compte ; mais c'est juste une contrainte de plus qui me paraissait intéressante ici).
2. L'orateur créé un salon Jitsi (par exemple) dans lequel on peut désactiver les caméras et avoir uniquement le son, et partage le lien unique généré en 1 dans le tchat Jitsi.
3. Quand la séance est finie, l'orateur clos la séance sur son interface de broadcasting, le fichier Sozi est alors supprimé (sinon il l'est dans les jours suivants).

Auquel cas la plateforme de broadcasting n'a pas besoin de beaucoup de ressources (le plus gros est fait par Jitsi), c'est typiquement quelque chose qui se ferait à coup de WebSocket (comme indiqué au dessus). Sozi est déjà fait en JS du coup le choix le plus évident serait peut-être NodeJS (mais c'est faisable avec n'importe quel langage). Ça me semble assez petit vu comme ça, mais bon c'est facile à dire quand ce n'est pas vous qui investissez votre temps libre, évidemment.

Le résultat intéressait peut-être Framasoft ; sinon est-ce que vos utilisateurs sont du genre à déployer leur instance ?

Difficile de répondre à ton problème, car il est complexe de manière général, et qu'on ne te connaît pas personnellement ; en revanche le fait de vouloir progresser est une très bonne chose (il n'y a pas pire que les gens qui pensent être bon et ne se remettent pas en question).

• Il faudra (si tu veux être compétent) toute ta vie continuer à étudier (ne serait-ce que des articles de blog sur des problématiques pointues, de nouveaux langages…) mais aussi pratiquer (sinon tu as tendance à te rouiller) ; donc pas de panique c'est une bonne chose de s'y mettre dès maintenant.
• Il est tout à fait normal que les premières solutions qui te viennent à l'esprit soient tordues ; on a tendance à envisager le cas nominal, puis à rustiner pour gérer les cas à la marge. On abouti alors à du code de piètre qualité. Donc premièrement n'hésite pas à attendre avant d'implémenter ta première idée et de réfléchir un peu plus (prendre 1 heure quand tu te lances dans un développement de plusieurs jour ça vaut le coup); deuxièmement ne t'attends pas à ce que ton code soit bon du premier coup, il est normal d'améliorer itérativement un code (tu es ton 1er relecteur en soit).
• Si tu as des collègues compétants qui te font des retours c'est là où tu vas apprendre le plus (car tu vas apprendre de tes erreurs, pas de celles des autres, ce qui est bien plus difficile). Si tes collègues te parlent de concepts que tu ne connais/maîtrises pas, c'est clairement qu'il faut un peu bosser ta théorie (ex: les design patterns, le couplage faible, la complexité algorithmique…).
• Concentre toi sur la qualité pas la quantité ; tu progresseras plus en perfectionnant du code, même si la tâche qu'il effectue te semble relativement simple, qu'en pissant des milliers de lignes. Si tu n'y arrives pas sur des petites choses, tu n'y arriveras pas sur des grosses.
• Avec le temps tu vas réussir à détecter les motifs qui se répètent dans ton code ; pas de problèmes de faire du copier-coller en première intention, mais ensuite ré-usine ton code en essayant de factoriser, de trouver des abstractions suffisamment génériques pour être utiles dans différents cas de figures et qui sont le plus faiblement couplée avec le reste du code. Je te conseillerai le développement piloté par les tests pour un ré-usinage moins stressant, mais aussi car en te forçant à faire du code testable il est souvent bien meilleur (limiter les états globaux par exemple).
• Balade toi dans le code des autres c'est intéressant de voir d'autres approches ; l'apprentissage d'autres langages (de préférence pas dans ta zone de confort) aussi.

J'espère que quelques uns de mes conseils te seront utile !

Le JIT a beaucoup plus d'info que la compilation AOT

Du côté de l'AOT, les techniques de Profile-guided optimization et autre AutoFDO permettent de réduire cet avantage du JIT ; il reste au JIT la possibilité de générer du code natif différent si 2 exécutions ont des profiles très différents.

Mais je serai curieux de savoir si en pratique cet avantage mène souvent à des différences de performances significatives.

(préambule: je ne suis pas un codeur Rust expérimenté, et serai donc bien incapable de tenir un débat trop technique là-dessus—mais l'avis d'un spécialiste m'intéresse aussi)

• Si j'ai bien compris, beaucoup de grosses applications finissent par mettre en place ce genre de design quand le fait d'avoir des pointeurs un peu partout devient ingérable.
• C'est un problème de gestion de ressource complexe par nature. Il n'y a pas de solution miracle j'imagine. Peut-être qu'une application qui consiste à 99% à manipuler un graphe sera moins pénible dans un autre langage, mais qu'une application qui ne fait ça que 10% du temps aura globalement à y gagner (ces 10% sont plus pénible mais les autres 90% bénéficient des vertus de sécurité/performances…). La question sera sûrement plus facile à répondre quand plus d'applications auront été écrites et qu'on aura plus de recul sur les avantages & inconvénients.

Rust ne permet pas de faire des cycles de références […] il n'est donc pas possible d'avoir des fuites de mémoire

Tu te trompes :
https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

(première ligne: "Rust’s memory safety guarantees make it difficult, but not impossible, to accidentally create memory that is never cleaned up (known as a memory leak").

sauf à utiliser des pointeurs faibles

Comme le dit le lien que j'ai indiqué, les pointeurs faibles servent à casser les cycles ; ils sont donc la (une) solution, pas le problème.

Une façon idiomatique en Rust de gérer les structures de données complexes consiste à utiliser des index plutôt que des pointeurs (les objet étant stockés dans une collection classique). J'ai cru comprendre que Rust fonctionne bien avec les systèmes à entités (ECS) du coup.

Mais oui dans certains cas on va avoir recours à des smart pointers ; un truc cool c'est que le compilateur va nous obliger à utiliser un compteur atomique (ARC) si on partage des objets entre plusieurs threads (on peut donc utiliser un comptage de référence classique plus performant dès que possible, sans peur de ne pas être thread-safe).

Mais via les cycles de référence il est tout à fait possible d'avoir des fuites de mémoires ; et donc un GC optionnel aurait du sens en effet.

Je te conseille de relire l'histoire du langage D (qui continue de bouger un peu).

Tu as quelques pépites sous le coude ? C'est sûrement parce que je m'intéresse beaucoup à Rust (et pas spécialement à D), mais j'ai l'impression que je vais avoir pas mal de briques en Rust dans ma distro Linux d'ici quelques temps (en plus de celles qu'il y a déjà), mais pour D, à part un shoot'em libre que j'avais testé y a quelques années ça n'a pas l'air d'être trop ça.

Alors je le répète, l'utilisation des langages de programmation, ce n'est pas un marché à se partager.

J'aimerai bien que tu développes, parce que pour le coup je ne suis pas entièrement d'accord. Je peux boire plusieurs types de soda, et même plusieurs types de cola, Koka et Paipsi sont quand même concurrents et se partagent un marché. Si on considère les nouveaux projet démarrés, j'imagine qu'on peut envisager l'ensemble des langages, dans lequel on va choisir, comme un marché ; et ce même sans tout percevoir de manière consumériste de manière générale.

Il y a aussi, par exemple, le fait que OpendBSD ait gardé un Big Kernel Lock (là où Linux & FreeBSD s'en sont débarrassé depuis pas mal d'années) afin de garder un code plus simple et sécurisé (mais empêchant d'avoir du parallélisme au niveau noyau).

Merci à Hybird de nous mettre à disposition un très bon CRM.

Je ne cacherai pas que ça fait plaisir de lire ce genre de choses.

J'ai conservé sqlite car il correspond à mon usage peu concurrentiel, moins de dix utilisateurs.

En matière de performances le nombre d'utilisateurs (et surtout le nombre de gens qui sont actifs en même temps, on s'en doute) n'est qu'un paramètre parmi d'autres. Le nombre de fiches en est un autre, et le genre de filtre qu'on va effectuer encore un autre (certains filtres bien poilus peuvent provoquer des jointures qui font exploser la combinatoire, et sont donc plutôt lourds pour le SGBD).

C'est un peu toute la difficulté (et donc l’intérêt évidemment) que d'essayer de répondre à des cas d'usage assez variés.

Mais des retours de performances sur une instance de Creme en production avec de vraies données, et basée sur sqlite, seraient intéressants (justement parce que c'est un cas que nous n'avons pas trop exploré ; c'est cool de voir des gens "s'approprier" le logiciel à leur guise).

Sur ce je retourne à mes vacances !

Oui c'est un truc piégeux de python que la façon dont le contexte est capturé ; on pense que chaque for va créer un nouveaux contexte, mais non, et du coup tes lambda utilisent la dernière valeur pour cat.

Il y a plusieurs façon de s'en sortir. Tu peux instancier ton instance de Button dans une fonction (chaque appel de fonction a bien son propre contexte—que va capturer ta lambda). Sinon il y a une astuce:

Ça c'est ce que tu fais :

functions = []
for i in range(3):
     functions.append(lambda: print(i))

for func in functions: 
   func()

et qui va afficher :
2
2
2

Mais si tu écris "functions.append(lambda x=i: print(x))" (note le paramètre nommé "x"—il pourrait s'appeler "i" aussi) alors ça écrira bien:
0
1
2