GuieA_7 a écrit 675 commentaires

Un langage tel que Rust peut-il s'attaquer à ce genre de problématique avec son mode de gestion automatique ?

Je pense que oui, parce que la gestion est certes automatique, mais prédictible (en plus pour les applications vraiment temps réelle l'allocation dynamique est proscrite en générale, et Rust permet ça aussi grâce aux allocateurs personnalisés).

PHP ça date de 1995, et Java de 1996 ; il est clair que Java est un truc de jeunes qui doit encore faire ses preuves ; vu le peu d'entreprises qui l'utilise, dans 10 ans ça aura sûrement disparu (après tout ça ne fait que quelques décennies que Cobol devrait avoir disparu).

Y en a marre de tous ces langages de hipster, alors qu'au final ça fait tout pareil que le basic de mon amstrad. Parce qu'au bout de 20 ans, il faut en apprendre un nouveau et ça c'est intolérable. En gros pour avoir ses 40 annuités il faut changer une fois (voire 2 !) de langage de prédilection. Ça c'est encore un coup de notre gouvernement et sa flexibilité du travail !

Cela étant, au début de Rust il y avait un GC qu'ils ont abandonné

Alors quelques précisions:
- le GC qu'il y avait au début de Rust n'étant pas un vrai GC, mais du comptage de références (parce que le travail n'était pas terminé).
- l'utilisation du GC a toujours pensée comme optionnelle : en gros on déclarait une référence comme étant "garbage collectable" (le langage a bien changé mais c'était dfans mon journal sur Rust 0.7 ).
- même quand le GC était partie intégrante du langage, le but était de s'en servir le moins possible, et par exemple la bibliothèque standard a vite atteint l'objectif de 0 GC.
- avec le temps l'équipe s'est aperçu qu'elle pouvait aller plus loin que ce qu'ils pensaient au début, et que le système de typage permettait de sortir le GC et de le penser comme une dépendance externe, sans besoin d'une syntaxe dédiée.

mais l'idée de remettre de la gestion automatique est toujours présente, cela semble être néanmoins compliqué

La gestion est déjà automatique, via le système de référence que j'ai (mal) expliqué, mais un GC optionnel serait un confort pour certaines partie de code. Ce qui complique la tâche ce sont les prérogatives assez élevées qu'imposent les buts du langage ('You pay for what you use' entre autres), quand Haskell/Ocaml/Java/Python… n'ont pas à se soucier de tels problèmes (mais ils en ont d'autres évidemment).

Sinon quelle différence fais-tu entre un langage qui peut faire de la programmation système et un langage système ?

La différence peut être mince, comme tu le soulignes avec les unikernels, mais je dirais qu'un langage système permet de maîtriser suffisamment parfaitement le comportement du code pour pouvoir écrire du code temps-réel (au sens temps réel dur, pas au sens globalement performant).

c'est pas si mal et bien mieux que le 25.82 s du meilleur code OCaml du test. D'autant que, n'étant pas moi même programmeur (je suis mathématicien et logicien, pas informaticien), il est fort probable qu'un spécialiste du langage puisse encore améliorer cela.

C'est très gentil de t'être donné la peine d'écrire un commentaire aussi argumenté, mais tu prêches un convaincu :) . Je sais très bien que Haskell ou OCaml ont de très bonnes performances dans la majorité des cas. Mais justement le lien que j'ai donné explique bien que Haskell va donner de très bon débit, mais va avoir des problèmes de latences ; ton benchmarck au final est équivalent à tester un débit moyen, mais ne va pas du tout tester les problèmes de latences, parce que 1) c'est pénible à tester 2) ce n'est pas ton problème.

C'est un système de lock pour les problèmes d'accès concurrents ? […]

Non pas du tout. Alors n'étant (encore :) ) pas un spécialiste du langage, mon explication va être un peu légère. En gros tout est fait à la compilation (un lock serait fait au runtime), où le compilateur, via son borrow checker, vérifie plusieurs choses comme:
- les temps de vie des objets. Par exemple si on retourne une référence sur un attribut d'un objet, alors le temps de vie de cette référence ne peut excéder celui de l'objet lui-même. Le borrow checker peut donc détecter des cas où on essaye de stocker cette référence en dehors du scope de vie de l'objet lui-même (un cas de dangling pointer comme on peut en trouver en C/C++).
- lorsqu'on passe une référence mutable à une fonction, on lui délègue la responsabilité de cette référence, et on ne peut plus utiliser cette référence dans la suite du code.

En pratique cela oblige à écrire le code de manière à satisfaire le borrow checker (sachant qu'il est régulièrement amélioré pour être moins stupide—il y a des fois où il est évident pour l'humain qu'il n'y a pas de problème, mais ça ne l'est pas pour le borrow checker). L'écriture des structure de données classiques est donc tout un art (heureusement le boulot est déjà fait !).

Au final c'est un peu comme quand les langages fonctionnels, qui en promouvant l'immuabilité et l'abandon des variables globales par exemple (ce que Rust fait aussi), obligent à penser son code d'une manière naturellement plus robuste.

J'espère avoir été clair.

Et on peut aussi manipuler des références (mais là c'est sans garde-fou) et faire de la programmation système en OCaml (la seule limite actuelle, c'est le GC qui ne gère pas les accès concurrents sur la major heap ce qui pose problème pour le parallélisme, cf multicore OCaml).

Ocaml permet de faire de la programmation système (ce qui ne veut pas dire grand chose, mais disons qu'un langage compilé nativement, avec de bonnes performances, qui permet de manipuler threads/sockets…, rentre dans cette appellation), mais à l'instar de Go par exemple, il ne peut pas être qualifié de langage système à cause de la présence obligatoire du GC (attention je n'ai jamais dit que tu avais affirmé que c'était un langage système—mais la précision me tient à cœur), tandis que Rust peut se passer complètement de runtime. Ça n'en fait pas un meilleur langage, c'est juste qu'ils ont des desseins différents.

Au passage, un petit article, que j'ai lu récemment, sur les problèmes qu'un GC peut poser (ici en Haskell): https://blog.pusher.com/latency-working-set-ghc-gc-pick-two/

l'attribut est un peu mieux décorrélé (mais pas totalement) de l'argument

Oui c'est ce que je disais dans mon commentaire avec "si les objets contenus sont mutable ils pourraient être modifiés de l'extérieur malgré ça"

Je ne sais pas ce que sont les notions de propriétaires/temps de vie en Rust, mais je dirais pour ma part : comme quoi le fonctionnel pur (ou l'observationnellement immuable) ça a son intérêt ! :-)

Tout à fait, d'ailleurs en Rust les variables sont immuables par défaut. Mais comme c'est un langage système qui vise aussi les performances optimales, il y a moyen de déclarer explicitement des variables mutables. Et le système d'emprunt de références va tout de même garantir qu'un seul endroit du code a la responsabilité de modification à un instant T. Ce qu'on perd en souplesse (le compilateur est encore plus hargneux, puisqu'en plus des règles sur types, on doit respecter les règles sur les références—et le système de typage est moins puissant qu'en Haskell/OCaml), on le gagne en performance.

Dans ce cas particulier, j'aime bien aussi :

class Test:
    def __init__(self, items=()):
        self.items = list(items)

Défaut:
- il y a forcément une copie, même si elle est potentiellement inutile (et du coup ça illustre bien comment, par exemple, les notions de propriétaire/temps de vie de Rust sont intéressantes pour des projets gros et devant être performants).

Avantages:
- puisque la liste nous appartient on peut la modifier sans trop de crainte (évidemment si les objets contenus sont mutable ils pourraient être modifiés de l'extérieur malgré ça).
- la fonction accepte du coup n'importe quel objet itérable (comme un générateur par exemple). Dans ton code items doit posséder une méthode append().
- même si ça ne dispense pas d'un commentaire sur l'API, la signature est plus explicite.

Dans le cas où 'items' n'a pas vocation à être très long (et qu'on n'a pas un 2ème argument du même genre), on pourrait aussi faire:

class Test:
    def __init__(self, *items):
        self.items = list(items)

du coup l'appel à la fonction serait Test(1, 2, 3) plutôt que Test([1, 2, 3]).

Comme quoi le "one way to do it" c'est (heureusement) une intention plus qu'une réalité :)

[…] s'attaquer à la difficulté de fond afin de faire établir ces idées comme principe ?

C'est à dire ? Faire voter une loi pour obliger les gens à ne faire que du logiciel libre ?

J'imagine que je ne suis pas le seul ici à connaître plusieurs entreprises qui n'utilisent pas de SCM du tout (décentralisé ou pas), parce qu'elles ne savent pas que ça existe ou ne savent pas vraiment à quoi ça sert. Celles que je connais sont de petites boîtes faisant des logiciels propriétaires.

Ça me fait froid dans le dos rien que d'y repenser :)

probablement inspiré de Rust au passage

Oui sûrement. Les 2 communautés s'inspirent mutuellement et c'est très bien comme ça, et très intéressant à suivre.

La gestion mémoire de Rust n'a rien de jeune. Elle vient des techniques de RAII de C++, Ada our Vala qui ont plus de 10 ans.
La seule "nouveauté" de Rust, est de les rendre obligatoire par défaut.

Rust a repris plein de concepts existants/éprouvés dans d'autres langages (C++, Haskell, Erlang, Python…), mais pour le coup sa gestion des références est réellement unique, et va plus loin que du simple RAII habituel (c'est sûrement inspiré du RAII, mais c'est bien plus que du RAII obligatoire). Le borrow checker n'a pas d'équivalent (à ma connaissance) ailleurs ; de plus, intégrer les autres concepts avec cette gestion mémoire, pour obtenir un tout cohérent, est aussi un tour de force en soi.

Rust est plus résistant aux buffer overflow que la plupart des langages des script, pourtant sa gestion mémoire est manuel

Je ne suis pas d'accord sur le terme 'manuelle' ; pour moi la gestion mémoire de Rust est automatique, mais faite (en grande partie) à la compilation, et pas à l'exécution (comme avec les langages à GC). Mais comme c'est un peu un OVNI, il n'est pas étonnant que l'abus de langage 'automatique==à l'exécution' se soit installé.

Globalement les autres commentaires ont déjà dit ce que je pensais globalement sur les exceptions ; à savoir: selon les cas tu vas en avoir plein pour gérer finement les erreurs et les rattraper, ou bien les attraper plus globalement pour des erreurs plus fatales.

Mais dans l'absolu sans voir ton code (ou une partie pertinente) il n'est pas forcément évident de donner une réponse satisfaisante:

• S'agit-il principalement d'erreur système ? Les message te semblent abscons pour l'utilisateur ?
• S'agit-il d'exceptions "algorithmiques" (KeyError, ValueError, TypeError…) ? auquel cas il y a souvent des alternatives plus courtes et aussi robustes que raisonner par exception.
• S'agit-il d'exception "Maison" ?

Je rajouterai que Python possède un arsenal d'outils efficaces permettant de factoriser le code si c'est l'aspect répétitif de ton code qui te gène.

Tu peux développer s'il te plaît, parce que pour le coup je ne sais pas trop si tu es d'accord avec moi ou pas ; le propos est en accord avec ce que j'ai dit (enfin c'est comme ça que je le comprends), mais dans la forme j'ai l'impression que tu essaies de me corriger.

Gagner de l'argent grâce au revenu de la publicité ou du porno sur un site installé sur un hébergement gratuit, n'est-ce pas gagner de l'argent grâce au travail d'autrui? aux travails de bénévoles?

Chaque fois qu'une entreprise gagne de l'argent avec un logiciel libre auquel a contribué un bénévole cette situation arrive. Et elle arrive donc tout le temps (ex: des gens qui contribue bénévolement à Linux). Ce n'est pas un problème, car le bénévole a volontairement contribué à un logiciel libre. Décréter que c'est un problème c'est ne plus vouloir de logiciel libre ("il est libre que si vous ne gagnez pas d'argent blablabla").

Et rien avoir de spécial à voir avec le porno ou la pub non plus ("Linux est libre, vous pouvez gagnez de l'argent, mais pas de gens tous nus qui copulent blablabla").

On pourrait même même étendre ton raisonnement à un particulier qui gagnerait du temps (ou prendrait du plaisir) grâce à un logiciel libre : au final il peut le faire grâce au travail des autres sans rien débourser ! C'est donc un salaud qui doit donner des thunes aux gentils développeurs bénévoles, ou bien contribuer !

Bref tu remets en cause le principe même du libre avec ton raisonnement. C'est ton droit, mais ne parle pas de compromis.

Autant dire que pour une grande majorité de gens, techniquement limité et qui n'ont pas 120$ à débourser pour leur blog personnel, tout ceci n'est plus tellement "libre" d'utilisation…

Les gens n'ayant pas d'argent pour se payer un ordinateur ne peuvent pas profiter de Linux, ni d'Olympe; donc on n'est pas vraiment libre de les utiliser non plus. Bref tu ne prouves rien ; 'logiciel libre' a une définition précise, tu peux quand même déconseiller un logiciel libre en particulier pour diverses raison tierce (support, performances, stabilité…).

Question peut-être stupide:

Y a-t-il une initiative pour faire une Base de Données libre et collaborative sur les livres (titre, édition, année de parution, ISBN etc…) ? J'imagine que ça serait utile à tous les projets cités ici.

À titre personnel j'utilise http://www.manga-sanctuary.com/ pour gérer ma collection de mangas (principalement être notifié des sorties, ça évite de faire le tour des sites des éditeurs régulièrement). Mais pour en avoir parler avec un pote libraire (il y a longtemps en tout cas), ils n'avaient pas l'air super ouverts au partage, et donc a avoir des applis tierces qui viendraient taper dans leur base ; donc mettre leur base en libre me semble improbable, et c'est bien dommage (et ça explique pourquoi je ne participe pas vraiment à la vie du site en question).

Et en plus ça les empêche de faire un jour de l'hébergement sur Hurd par exemple (mais bon y a le temps :) ).

Un développeur désirable pourra, s'il le souhaite, choisir en grande partie l'entreprise où il travaille, avec les avantages et inconvénients que chacune comporte ; tout étant une question de priorité au final.

Ton commentaire sent la frustration à plein nez (à moins que ça soit du troll).

Accumulation de framework à la mode

Oui, mais le défaut opposé, à savoir préférer tout écrire soi-même en pensant que le boulot des autres est mauvais, est aussi très répandu.

J'ai un pote qui est l'archétype du PHPiste qui n'a jamais essayé d'aller plus loin dans ses connaissances théoriques ; il affirme qu'il n'utilisera jamais de framework (parce que c'est des "gros tas de merde"), mais il ne faut pas discuter très longtemps pour s'apercevoir de ses lacunes. Dernier exemple en date: alors que les bons frameworks web protègent plus ou moins automatiquement contre les failles CSRF, il n'en avait même jamais entendu parler ; l'excuse étant "je n'ai pas le temps de m'occuper de tout" ainsi que "comment je peux être au courant de ce genre de choses ?" (et oui forcément quand tu passes ton temps à - mal - réinventer la roue…).

Ah oui, c'est un professionnel, dans le sens où il est payé pour ça :)

Comme Python, il s'agit d'un langage non typé

Python (et GDScript aussi je présume) est typé, mais dynamiquement, et fortement aussi (même si c'est relatif comme notion). Il suffit de faire "bidulos" + 1 pour comprendre.

Sinon j'ai très envie depuis longtemps de tester Godot (ainsi que SuperPowers), mais il va falloir poser des vacances pour ça :)

Je ne sais pas vous, mais j'ai l'impression de revivre le même scénario qu'il y a 20 ans

Il est fréquent que des techniques parfois délaissées un temps réapparaissent sous une autre forme plus tard, et ça n'a rien de problématique dans l'absolu ; c'est juste que tu te focalises sur les ressemblances (parce que c'est attirant, que tu as envie de prédire le futur de manière simple) en oubliant les différences. Par exemple avec Rust et Go, on reprend goût à faire applications web avec des langages compilés en natif et ce n'est pas pour ça qu'on va retomber dans les travers des CGI en C.

En l’occurrence Java était fait par une seule entreprise dans son coin, alors que là on à affaire à un standard conçu par les acteurs du Web ; alors évidemment les erreurs de design sont possibles, mais les gens qu'il y à derrière sont sûrement les plus qualifiés pour faire le taff. Et puis il y a des erreurs de design même dans unix/posix (même si elles ont mis longtemps à être découvertes), mais bon la seule façon de ne pas faire d'erreur c'est de ne rien faire.

Les développeurs d'application (pas tous) s'en fichent un peu du web, de faire du contenu

Les développeurs qui ne veulent pas faire de web peuvent continuer à ne pas faire de web, je ne vois pas où est le problème. Si l'idée c'est d'arrêter d'améliorer les technologies web pour que les autres technologies restent dans la course, ça me parait être une mauvaise façon de raisonner.

Pourquoi en arrive t-on là ? A mon sens en grande partie à cause des logiciels privateurs

Je ne pense pas, vu comment les langages de script (Sh, Python, Ruby…) sont populaires, même en se focalisant dans les logiciels libres n'ayant pour vocation que de tourner sur les unix libres.

La diversité me semble faire toujours du bien sur le long terme

Il va y avoir plusieurs implémentation de la VM WebAssembly (tout comme on a plusieurs VM JavaScript), et sûrement des tas de langages qui vont générer du WebAssembly (tout comme des tas de langages génèrent déjà du JS; sauf que ça devrait être bien mois crade). Donc de la diversité il va y en avoir ne t'inquiète pas ! :)

(Microsft aime linux au point de l'étranger à mort avec des breverts pendant que les médias ne regardent pas)

MicrosOft
Linux
étrangLer
breverts -> brevets

Mais bon, je ne cherche pas à convaincre, c'est juste mon expérience après avoir étudié et essayé les deux.

Je ne doute pas que ton expérience soit intéressante, mais tu donnes peu de détails sur cette dernière qui permettrait de donner une idée de son aspect universel (si tu l'as expérimentée sur 12 applis de 500K lignes dans 5 langages, ce n'est pas pareil que 3 applis de 150 lignes dans 1 langage), tout en balançant des généralités ("les micro-frameworks c'est mieux sur le long terme").

Personnellement je bosse quotidiennement sur une application en Django depuis 2009 (et le prototype date de 2007), et la maintenance n'est pas un problème, sachant qu'on a commencé avant la 1.0, et qu'on utilise actuellement la 1.8. Il nous arrivent régulièrement d'atteindre les limites du framework, et je ne veux absolument pas à dire qu'il est parfait (non il est même très perfectible) ni lui faire spécialement de publicité (il n'en a pas besoin, et des tas d'outils de qualité bénéficient de moins de visibilité). Mais au final ce qui me limite le plus c'est mon propre code, et les quelques problèmes techniques que me posent le framework sont complètement anecdotiques par rapport à tout ce qu'il peut m'apporter par ailleurs.

Maintenant j'admets tout à fait que dans l'absolu le design monolithique de Django est moins élégant que le design d'un Pyramid par exemple; et je suis content qu'il existe des alternatives à la philosophie différente. Mais en l'occurrence Pyramid n'existait pas quand on a commencé le projet (je ne sais plus si Pylons existait à l'époque) ; je serai bien incapable de dire ce qui se serait passé si on avait utilisé autre chose (il faudrait une machine à voyager dans le temps pour ça), mais vu que Django a évolué de manière efficace (en cassant des choses quand il le fallait, mais en essayant de rendre les cassures les moins pénibles possibles), je doute que les choses auraient pu se passer beaucoup mieux.

Mouais, je ne me suis pas vraiment convaincu. Lorsque tu as 30K lignes de template Machin et 50K lignes de code utilisant l'ORM Bidule, quand bien même tu peux changer ton moteur de template ou ton ORM, tu ne vas pas le faire car tu devras quand même réécrire énormément de choses. Alors oui tu vas peut être pouvoir changer des composants secondaires, mais je pense que le choix des composants principaux se fera au début du projet et ne changera plus lorsqu'une masse critique de code sera atteinte.

On retrouve cette philosophie en Go, de ne pas s'encombrer de ce qui pourrait devenir un boulet par la suite.

Lorsque ton code grossi, il devient son propre boulet. Regarde FireFox ou OpenOffice (programmes que je respectent énormément mais qui illustreront très bien mon propos): ils n'utilisent pas de framework, pourtant les faire évoluer est très complexe, même si leurs développeurs sont eux mêmes écrits la plupart du code, parce que les décisions de design d'il y a plus de 15 ans ne sont plus forcément pertinentes aujourd'hui etc… Et OpenOffice passerait volontiers à Qt (un framework donc) si ça ne représentait pas tant de travail que ça de changer son propre code tout-écrit-à-la-main-sans-dépendance-à-un-framework.

Lorsqu'il y a aura pléthore de programmes en Go de plusieurs millions de ligne, que les gens auront essayé de s'en servir pour plein de choses pour lesquelles il n'était pas prévu à la base (ce qui est naturel et moteur de progrès), tu en trouveras plein des programmes en Go qui se traînent des boulets.

… moi qui croyais pouvoir vivre de ma passion c'est pas gagnez :-/

J'ai l'impression qu'il y a un paradoxe dans tes propos (mais je peux me tromper). On dirait que tu dis "le logiciel libre c'est cool j'ai envie d'en faire, mais fournir les sources c'est pénible car je veux gagner de l'argent avec, je le fais parce que je suis obligé". L'impression que ça me laisse c'est que tu aimes le libre… quand les autres en font.

Pour vivre de ta passion, c'est pas l'obligation de fournir les sources qui va te poser problème. Le problème c'est de fournir quelque chose pour lequel les gens sont prêt à payer. Quand bien même tu pourrais faire ta distro Linux sans donner les sources, qui va te donner de l'argent pour ta distribution sortie de nulle part, alors qu'il en existe déjà des tas qui fonctionnent très bien et qui sont gratuites ? Au final, les entreprises qui gagnent de l'argent en faisant des distro le font grâce au support (le service autour du logiciel donc) et pas à la vente de licences. Si tu veux les concurrencer, il faudra apporter quelque chose de différent ; parce que quitte à a voir la même chose, les gens iront prendre les 'produits' connus et éprouvés.

Mon associé et moi avons changé de portable récemment (lui un Lenovo, moi un HP), et nous avons tous les 2 été confrontés au fait qu'une même image, mais écrite sur différentes clés USB, va parfois fonctionner et parfois non (4 clés différentes, une seule qui fonctionne dans notre cas). Si tu peux, essaye donc avec plusieurs clé (et oui c'est pénible).

PS: as-tu activé la compatibilité BIOS ? (probablement désactivée par défaut si l'ordinateur est sous Windows10)