Une bonne Loi devrait imposer deux choses pour une nouvelle offre:
la non réponse devrait impliquer la rupture du contrat et non l'acceptation des modifications ;
une égalité de moyen entre la question et la réponse. Pas de "dite oui oralement au téléphone" mais "dite non par lettre recommandée à une adresse que je ne vous donne pas, cherchez la sur mon site elle est bien cachée nanananèreu"
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Ce que je voulais dire par ma question, c'est que si on veut réduire l'impact écologique des voitures, il va falloir changer à la fois de type d'énergie, mais aussi de type de véhicule.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
libgdx, pygame,… sont en C ou C++ plus qu'en python ou java quand ce n'est pas simplement sdl qui fait toutes la partie critique en terme de perf par exemple
Logique ce sont des bindings, mais une bonne partie du code est quand même dans le langage à GC. Avec le code des jeux qui l'utilisent, ça fait une majorité du code final sous GC.
Parce que la mémoire n'est pas géré par le garbage collector. Quand ut garde une taille de heap petite ça fonctionne bien.
Logique aussi, une bonne partie de la mémoire dans un jeu, ce sont les vertices, les shaders et les textures qui ne sont même pas en RAM et qu'il faut de toute façon gérer à la main, GC ou pas GC.
Il y a aussi beaucoup d'autres données, par exemple le moteur physique qui lui bombarde bien la RAM et là aussi il faut optimiser à coup de préallocations et de piscines. GC ou pas.
Bref les GC modernes ne sont pas un problème dans les jeux. Ni dans les applis web, ni dans 99% des applis. Il faut simplement ne pas te rater quand tu es dans le 1% des cas qui demande une gestion manuelle.
Ca ne veut pas dire que les GC sont une meilleure approche que les "pointeurs intelligents", mais juste une solution plus simple et plus générale.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Je ne sais pas trop ce que tu veux dire par "en frontend", mais beaucoup de jeux utilisent un langage GC comme langage principal et pas seulement comme langage de script.
Regarde ce qui se fait avec les cadriciels Java (libgdx, lwjgl), Python (pygame), C# (monogame, Unity), Lua (Löve).
L'accès aux API graphique/sonore/inputs se font toujours en C, mais la majorité du code et donc des allocations mémoires sont pris en charge par le GC.
Pourquoi ces jeux sont fluides et n'ont pas de gros ralentissements dû à un ramasse miette Arrête Le Monde? Parce que d'une part, comme je l'ai déjà dit, les GC modernes ramassent les mettes de façon incrémentales et concurrentes, d'autre part les développeurs de jeux font la chasse aux allocations/désallocations en pré-allouant un maximum de choses, en utilisant des pools, en préférant des tableaux fixes aux hashmaps dynamiques…
Cette chasse est faite aussi dans les jeux en C/C++, car comme je l'ai déjà dit aussi, les malloc/free, c'est coûteux pour tout le monde, pas seulement quand c'est un GC qui les fait.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Euh, les fuites mémoires à cause d'évènements ou d'objets non-disposés (utilisant des connexions à des bases de données, des ressources réseau, des Span, …), ça arrive et ça fait mal.
J'ai rarement eu besoin des weak references et à chaque fois c'était pour des ressources systèmes (les textures dans Newton Adventure par exemple :-) ) qui de toute façon demande une gestion particulière.
Est-ce qu'il ne vaut pas mieux un langage avec un GC pour 99% des allocations et gérer à la main le 1% qui reste?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
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).
On fait ça aussi en C ou en C++. C'est parfois utile, mais ça ne change pas le problème: au lieu de faire attention à mes pointeurs, je dois faire attention à mes indexes.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Ce qui me vient en tête immédiatement, c'est un code qui manipule des graphes.
En java ou C, je vais avoir des classes ou structures Graph, Edge et Node.
En C, il faudra faire bien attention à passer free partout, au bon moment et dans le bon ordre.
En C++, on va choisir avec soin quelles références seront des unique_ptr, des shared_ptr ou des weak_ptr selon les cas d'usage.
Avec un ramasse miette, chacune peut avoir des références sur les autres, on ne va pas se préoccuper de la durée de vie des objets, des pointeurs forts ou faibles… Osef on a de la RAM et le GC passera le balai !
Et avec Rust ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
The flexibility (i.e. expressiveness) of non LIFO-semantics means that in general the compiler cannot automatically infer at compile-time where memory should be freed; it has to rely on dynamic protocols, potentially from outside the language itself, to drive deallocation (reference counting, as used by Rc and Arc, is one example of this).
Donc Rust fait juste comme C++ et ses smart pointers?
Je comprends mieux le ticket pour ajouter un ramasse miette à Rust.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
En analysant le code, on peut éviter d'utiliser le ramasse miette pour les allocations / désallocations les plus courantes.
Si tu as un code simple comme:
function postCoincoinDuJour() {
let linuxfr = new LinuxfrBoard();
let message = "Coincoin du " + new Date().getDay(Lang.FR);
linuxfr.post("Coincoin");
} Un bon compilateur va déduire que les objets LinuxfrBoard et Date ne s'échappe pas de la fonction. Il peut décider de ne pas les laisser au ramasse miette, mais de les allouer sur la pile.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Comment Rust gère les cas non triviaux de libération de la mémoire (ce qu'un bon compilo pour langage à garbage collector peut gérer automagiquement) ? Par exemple une structure de type graphe ou récursive?
L'écosystème compte énormément. Et le poids de l'existant également. Et C++ est en train de rattraper son retard sur Rust sur tout un tas d'aspect et a plein de qualités également.
Qu'est-ce qui a été rattrapé?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Tu as déjà bossé dans une association ou une petite entreprise? A quel moment les utilisateurs arrivent avec une expression de besoin cohérente et un cahier des charges précis ?
En général ils se plaignent du SI en place (c'est lent, c'est compliqué…), mais n'ont aucune idée de ce qu'il leur faudrait, encore moins de ce qui est possible et jamais de ce qui est faisable avec des coûts et des délais raisonnables.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
En v2, la liste de tes amis sera déterminés automatiquement par une intelligence artificielle chargée de choisir les personnes les plus à même de faire augmenter ton pouvoir d'achat et ta consommation.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Article L224-33
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Les pratiques commerciales de BouyguesTelecom. Évalué à 9.
Une bonne Loi devrait imposer deux choses pour une nouvelle offre:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 3.
Ça me rappelle ce nourjal https://linuxfr.org/users/devnewton/journaux/veuillez-instancier-ce-journal-avant-de-le-lire !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Quelles voitures?
Posté par devnewton 🍺 (site web personnel) . En réponse au lien Coup de tonnerre : les voitures électriques ne seraient pas écologiques !. Évalué à 3.
Ce que je voulais dire par ma question, c'est que si on veut réduire l'impact écologique des voitures, il va falloir changer à la fois de type d'énergie, mais aussi de type de véhicule.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Quelles voitures?
Posté par devnewton 🍺 (site web personnel) . En réponse au lien Coup de tonnerre : les voitures électriques ne seraient pas écologiques !. Évalué à 5. Dernière modification le 08 septembre 2020 à 17:11.
Une Tesla de plus de deux tonnes ou une Citroën Ami de moins 500kg?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 3.
C'est souvent utilisé dans le moteur physique qui est critique.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 3. Dernière modification le 08 septembre 2020 à 14:50.
Logique ce sont des bindings, mais une bonne partie du code est quand même dans le langage à GC. Avec le code des jeux qui l'utilisent, ça fait une majorité du code final sous GC.
Logique aussi, une bonne partie de la mémoire dans un jeu, ce sont les vertices, les shaders et les textures qui ne sont même pas en RAM et qu'il faut de toute façon gérer à la main, GC ou pas GC.
Il y a aussi beaucoup d'autres données, par exemple le moteur physique qui lui bombarde bien la RAM et là aussi il faut optimiser à coup de préallocations et de piscines. GC ou pas.
Bref les GC modernes ne sont pas un problème dans les jeux. Ni dans les applis web, ni dans 99% des applis. Il faut simplement ne pas te rater quand tu es dans le 1% des cas qui demande une gestion manuelle.
Ca ne veut pas dire que les GC sont une meilleure approche que les "pointeurs intelligents", mais juste une solution plus simple et plus générale.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 6.
Je ne sais pas trop ce que tu veux dire par "en frontend", mais beaucoup de jeux utilisent un langage GC comme langage principal et pas seulement comme langage de script.
Regarde ce qui se fait avec les cadriciels Java (libgdx, lwjgl), Python (pygame), C# (monogame, Unity), Lua (Löve).
L'accès aux API graphique/sonore/inputs se font toujours en C, mais la majorité du code et donc des allocations mémoires sont pris en charge par le GC.
Pourquoi ces jeux sont fluides et n'ont pas de gros ralentissements dû à un ramasse miette Arrête Le Monde? Parce que d'une part, comme je l'ai déjà dit, les GC modernes ramassent les mettes de façon incrémentales et concurrentes, d'autre part les développeurs de jeux font la chasse aux allocations/désallocations en pré-allouant un maximum de choses, en utilisant des pools, en préférant des tableaux fixes aux hashmaps dynamiques…
Cette chasse est faite aussi dans les jeux en C/C++, car comme je l'ai déjà dit aussi, les malloc/free, c'est coûteux pour tout le monde, pas seulement quand c'est un GC qui les fait.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 3.
Comme dit plus haut, regarde le nombre de jeux écrit avec un langage à GC.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 5.
Aujourd'hui les vraies pauses sont si petites qu'on ne les remarque plus (CTB !).
Il y a même un GC pauseless pour Java, mais il n'est pas libre :(
Note aussi que le temps d'exécution des autres modes de libération de la mémoire n'est pas NULL non plus.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 3.
Les premiers GC stoppaient le monde. Les modernes travaillent de façon incrémentale et parallèle.
Beaucoup de jeux utilisent un langage à ramasse miettes sans problème: tous les jeux Java, html5, Unity, Lua…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 5.
J'ai rarement eu besoin des weak references et à chaque fois c'était pour des ressources systèmes (les textures dans Newton Adventure par exemple :-) ) qui de toute façon demande une gestion particulière.
Est-ce qu'il ne vaut pas mieux un langage avec un GC pour 99% des allocations et gérer à la main le 1% qui reste?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 4.
On fait ça aussi en C ou en C++. C'est parfois utile, mais ça ne change pas le problème: au lieu de faire attention à mes pointeurs, je dois faire attention à mes indexes.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 6.
Ce qui me vient en tête immédiatement, c'est un code qui manipule des graphes.
En java ou C, je vais avoir des classes ou structures Graph, Edge et Node.
En C, il faudra faire bien attention à passer free partout, au bon moment et dans le bon ordre.
En C++, on va choisir avec soin quelles références seront des unique_ptr, des shared_ptr ou des weak_ptr selon les cas d'usage.
Avec un ramasse miette, chacune peut avoir des références sur les autres, on ne va pas se préoccuper de la durée de vie des objets, des pointeurs forts ou faibles… Osef on a de la RAM et le GC passera le balai !
Et avec Rust ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Lien avec la censure des GAFAM à propos de la pseudo-pandémie ?
Posté par devnewton 🍺 (site web personnel) . En réponse au lien Les clients Mastodon seraient bannis de Google Play pour cause d'incitation à la haine. Évalué à 4.
Ca peut intéresser nos lecteurs pour rire un bon coup !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 3.
Donc Rust fait juste comme C++ et ses smart pointers?
Je comprends mieux le ticket pour ajouter un ramasse miette à Rust.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 4.
En analysant le code, on peut éviter d'utiliser le ramasse miette pour les allocations / désallocations les plus courantes.
Si tu as un code simple comme:
function postCoincoinDuJour() {
let linuxfr = new LinuxfrBoard();
let message = "Coincoin du " + new Date().getDay(Lang.FR);
linuxfr.post("Coincoin");
}
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 4.
Comment Rust gère les cas non triviaux de libération de la mémoire (ce qu'un bon compilo pour langage à garbage collector peut gérer automagiquement) ? Par exemple une structure de type graphe ou récursive?
En les interdisant?
https://github.com/rust-lang/rfcs/issues/415
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: SMTP
Posté par devnewton 🍺 (site web personnel) . En réponse au lien RFC 8890: The Internet is for End Users. Évalué à 3.
Ça peut se résoudre avec des messages d'invitation.
Alors oui les spammeurs vont envoyer des invitations à la terre entière, mais au moins on pourra mettre ces messages à part, leur assigner un TTL…
Voire un serveur pourrait greylister un vil qui se fait refuser trop d'invitations :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Notre retour d'expérience à WebAssoc
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Logiciels libres dans une association non-informatique. Évalué à 4. Dernière modification le 04 septembre 2020 à 17:02.
Il y a du Rust dedans aussi !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: On se focalise sur l'utilisateur SVP
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Logiciels libres dans une association non-informatique. Évalué à 5.
Je répondais à pasBill pasGates et on est vendredi, donc troller est un devoir !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 5.
On pouvait déjà faire du natif sans C: Pascal, Ada et plus récemment Go.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 7.
Qu'est-ce qui a été rattrapé?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: On se focalise sur l'utilisateur SVP
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Logiciels libres dans une association non-informatique. Évalué à 10.
Tu as déjà bossé dans une association ou une petite entreprise? A quel moment les utilisateurs arrivent avec une expression de besoin cohérente et un cahier des charges précis ?
En général ils se plaignent du SI en place (c'est lent, c'est compliqué…), mais n'ont aucune idée de ce qu'il leur faudrait, encore moins de ce qui est possible et jamais de ce qui est faisable avec des coûts et des délais raisonnables.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tu prends le probleme a l'envers
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Logiciels libres dans une association non-informatique. Évalué à 7. Dernière modification le 04 septembre 2020 à 08:13.
Le souci est souvent que les utilisateurs ne savent pas exprimer leur besoin…
Nombre d'entreprises choisissent Sharepoint pour faire de l'édition collaborative de documents avec les conséquences qu'on connait…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: SMTP
Posté par devnewton 🍺 (site web personnel) . En réponse au lien RFC 8890: The Internet is for End Users. Évalué à 5.
En v1, ce sera une demande d'ajout !
En v2, la liste de tes amis sera déterminés automatiquement par une intelligence artificielle chargée de choisir les personnes les plus à même de faire augmenter ton pouvoir d'achat et ta consommation.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.