Je n'ai jamais prétendu le contraire ; C++ évolue sans casser la compatibilité et c'est très bien au vue du nombre de logiciels écrits en C++. Mais du coup C++ se traînera toujours certains boulets, malgré toutes ses évolutions.
Rust apporte une solution à bon nombre de ces boulets ; ça ne veut pas dire qu'il est parfait. On peut même être sûr que s'il est toujours utilisé dans 30 ans (ce qui n'est pas gagné encore une fois), on aura largement eu le temps de lui déceler des tas de boulet à lui aussi.
Après tu as tout à fait le droit de douter de l'intérêt de Rust. Mais les arguments à base de "C++ c'est utilisé depuis 30 ans dans des millions de logiciels nananère" ne sont pas franchement très intéressants. Oui c'est vrai la popularité de C++ est un avantage sur tous pleins d'aspects ; mais bon ici on est sur linuxfr, on en connaît plein des logiciels géniaux qui ne sont pas hyper connus, mais qui arrivent à vivre depuis longtemps (tout le monde ici connaît Blender , pourtant c'est loin d'être le cas de tous les graphistes).
Je n'ai vu personne sur le thread dire qu'il fallait réécrire tous les logiciels C++ en Rust ; et pour une bonne raison c'est que ça serait stupide. En revanche pour un nouveau logiciel (et des logiciels libres qui manquent ben y en a des tas), cela peut être un choix intéressant.
En fait depuis le début j'ai l'impression que quand les gens écrivent "Rust est peut-être le C++ du futur", tu lis "le C++ c'est de la merde, et les devs C++ sont des idiots" : ce n'est absolument pas le cas ! Les créateurs de Rust ont beaucoup pratiqué le C++, l'aiment et suivent de près ses évolutions ; ils sont confrontés aux mêmes problèmes, et les solutions du C++ sont très réfléchies.
Déjà bravo pour le travail accompli ; il y a un mois j'avais vu passé le projet sur FreeGamer, et la vidéo de l'éditeur de carte est vraiment très sympa.
En revanche je m'interroge : y a-t-il des fonctionnalités qui vous différencient de Spring ?
Par exemple je ne pense pas que Spring permette de faire autres chose que des classiques maps rectangulaires ; alors que dans le monde propriétaire j'aime beaucoup (sans y avoir jouer) Planetary annihilation qui propose des maps qui sont des systèmes solaires avec de petites planètes ! Mais pour le coup, OpenRTS m'a l'air tout aussi classique (c'est juste une fonctionnalité qui me parait intéressante, mais il y a sûrement moyen d'innover sur d'autres fronts).
Qu'on compare Rust à Go, par exemple, me semble bien plus pertinent. Mais bizarrement, ça n'est jamais fait.
Dans mon journal sur la version 0.7 je comparais déjà Rust à Go (et j'expliquais en quoi ces langages sont très différents sur bien des plans).
À côté de ça Rust a vraiment une philosophie proche de C++ ("What you don’t use, you don’t pay for") ; par exemple voir ici une explication très intéressante sur les traits.
Et sur le reddit de Rust, les clashes avec Go et C++ sont tous les deux très courants.
Au moins, les développeurs de Go, ils sont conscients, ils ont une vraie vision du marché et ils s'aperçoivent bien que le gros des développeurs Go, ce ne sont pas des développeurs C/C++, mais des développeurs Python/Ruby.
Mouais ils ont écrit Go pour leur propre usage (comme Mozilla), et au bout d'un certain temps à essayer de le 'vendre' aux développeurs C++ se sont aperçus que c'est plutôt les dev Python/Ruby que ça intéressait ; ce n'est pas une critique en soit, mais de là en faire des génies du marketing… Bien des réussites de l'industrie étaient complètement inattendues, et aujourd'hui mis à part les géants que sont Microsoft (avec C#) ou Apple (avec Objective-C et Swift), aucune entreprise n'est capable d'imposer un langage ; les autres ben ils essaient de faire de leur mieux et parfois c'est un succès. Mais bon on peut aussi dire que C++ c'est le mieux que pourra faire l'humanité et donc on arrête de chercher tout de suite.
L'industrie ne peut pas se permettre deux concurrents, et souvent, l'un des deux meurt. Ou alors trouve sa niche mais dans ces cas là, ils ne sont plus concurrents, chacun vit sa vie de son côté.
C'est vrai, quelques langages se taillent la part du lion, et les autres se retrouvent bien souvent à vivoter (au mieux). D'un autre côté on a aussi les couples C#/Java et Python/Ruby, dans lesquelles des langages quand même très proches évoluent en parallèle (restant concurrents) et ont tous des communautés suffisamment dynamiques pour trouver un peu tout ce qu'on veut en terme de bibliothèques.
Le potentiel c'est quand même important ; Javascript (ou Python/Go/Java/… peu importe) ne pourront jamais être aussi rapides (ou léger en mémoire) que C/C++, car leur sémantique les en empêchera toujours. À côté de ça, les performances de ces différents langages ont largement eu le temps de s'améliorer depuis leur 1.0 ; Go par exemple était en 1.0 il n'y a pas si longtemps, et les performances n'étaient pas terribles.
Pour l'instant, ils ont fait les optimisations faciles
Il reste, je crois, encore pas mal d'optimisations assez faciles (le code de rustc n'étant pas forcément génial), le plus important ayant été de stabiliser la sémantique du langage, afin de s'assurer par exemple que les évolutions futures soient réalisables sans tout casser. En effet le concept des références/temps de vie est différent de ce qu'on connaît ailleurs, et nécessite souvent de concevoir son code de manière différente ; il était important que cette nouvelle approche ne soit pas globalement une régression.
Il n'y a pas si longtemps par exemple un simple 'Hello world' en Rust prenait plusieurs Mo (car il embarquait toute la lib standard, un truc comme ça).
Évidemment aller chercher le potentiel demandera du temps et des ressources, et rien ne garanti qu'il sera atteint un jour. Les résultats actuels sont déjà très intéressants, on peut donc faire preuve d'un certain optimisme !
Et surtout, il pourra s'approcher du C/C++ sans le dépasser parce qu'il utilise la même technologie (LLVM) que Clang.
Pas forcément. Au alentours de la 0.7, je me rappelle que rustc était déjà capable dans certains cas d’émettre des informations d'aliasing pour LLVM (et qui permettent des optimisations), et qui ne pouvaient pas être émises par du code C++ (le langage n'ayant pas la sémantique adéquate).
À l'heure actuelle, pour réussir à allumer 1 pixel, il faut se taper une bibliothèque… non, pire en fait, un framework complet… À l'époque ou l'accès au matos était direct, il suffisait de quelques lignes d'assembleur, de l'ordre de quelques 10aine
Mouais bof.
Tu prends 2 minutes (sûrement moins en fait sur n'importe quelle distro linux) pour installer pygame (par exemple), et pareil en 10 lignes tu fais une fenêtre et tu affiches un sprite. En quelques lignes tu peux le faire bouger avec les touches du clavier ; en 2 lignes tu joues une musique de fond, et 20 lignes tu fais un système basique de lecture/écriture de sauvegarde ; etc…
Que tu aies découvert les joies de la programmation avec l'assembleur, très bien. Je suis aussi passionné que toi, mais moi j'ai commencé par le BASIC (et j'ai fait du langage assembleur plus tard, en école d'ingénieur). Et les jeunes d'aujourd'hui, ils découvriront leur passion avec encore autre chose, peu importe.
Quand je vois le mal que mes profs d'info ont eu (2006-2007) à expliquer aux autres ce qu'était un pointeur ensuite, alors que la plupart des gens venaient de STI électronique, je me demande si commencer par du matos et des techniques obsolètes mais simples n'a pas un certain intérêt.
Pour moi tous les professionnels de la programmation doivent avoir fait pendant leur cursus de la programmation en langage assembleur (mais aussi en C, et de l'objet, et du fonctionnel, mais c'est un autre problème) et savoir un minimum comment fonctionne un processeur. Pendant mes études (2001/2004) c'était du MIPS (mais simulé, pas de machine physique), et c'était très bien. Mais dire qu'il faut commencer la programmation par là, alors non, c'est vraiment un autre problème.
Les passionnés, dans un domaine qui s'est autant répandu, sont toujours une minorité ; la plupart des programmeurs ont choisi ce domaine parce qu'ils pensent qu'ils pourront trouver du boulot . Ça ne veut pas dire qu'ils trouvent ça inintéressant, juste qu'il ne passeront pas des heures sur leur temps libre à coder par exemple. C'est triste, mais moi aussi en fin de cursus d'ingénieur, des tas de mes camarades ne savait même pas faire des malloc()/free() correctement ; cela n'a pourtant pas grand chose à voir avec une quelconque simplicité des outils, juste le fait de ne pas trop avoir envie de se creuser la tête…
Dans mes souvenirs qu'il y a quelques années, les développeurs d'OpenBSD avaient choisit que garder le verrou global, car mettre des verrous plus fins, en rendant le code plus complexe (et donc plus dur à auditer d'un point de vue sécurité) ne valait pas le coup dans leur optique de sécurité avant tout.
Qu'est ce qui a changé depuis ? Les problèmes de performances, avec la présence de multi-core dans la machine de Mme Michu, ont-ils rendu à présent le compromis intéressant ? Sont-ils plus nombreux pour pouvoir maintenant auditer un code plus complexe ? Ont-ils juste changé d'avis ?
Pourtant c'est très possible ; pas à Paris j'imagine, mais en province si (je suis à Marseille). J'ai été au SMIC pendant plusieurs années (monter sa boite c'est travailler plus pour gagner moins :) ), et oui économiser 250€ par mois était habituel :
500€ de loyer (y a moyen de trouver moins cher et plus grand, mais j'ai choisi de rester dans un quartier qui me plaît plus).
200€ de bouffe par mois (et en achetant pas mal de bio).
100€ pour assurance, internet, électricité, gaz, bus/métro (la moitié est payée par l'employeur).
il reste encore 80€ pour les loisirs (si je table sur 250€ d'économie).
Tout d'abord je tiens à dire que je trouve votre projet très intéressant. En revanche, il soulève pas mal d'interrogations chez moi.
Quand tu parles de film, tu parles d'un long métrage (genre plus de 1h) ?
Sur votre site je n'ai pas vu la composition de l'équipe ; en plus de toi et d'Ahryeom, combien êtes-vous pour faire l'animation ?
Lorsque vous mettrez en place la campagne de financement, y aura-t-il ne serait que quelques secondes d'animation (genre mini bande annonce) pour se rendre compte de la qualité de l'animation finale ?
BlueMind distribue aussi au moins un plug-in proprio et payant et fait du service payant (heureusement pour eux), je ne vois pas en quoi ça peut être qualifié de "modèle totalement gratuit".
Linagora vend principalement du service autour de logiciels libres qu'ils n'ont pas forcément développés (genre LibreOffice)(ce qui n'est pas un reproche encore une fois) ; donc pas de "modèle totalement gratuit" dans ce cas là non plus.
de manière général aucune boite ne peut avoir un "modèle totalement gratuit", ça n'a pas de sens.
Si tu voulais dire qu'ils développent entre autre du logiciel libre (et gratuit), ben il fallait le dire. Mais bon c'était plus facile de balancer 3 questions absconses sans début de réponse, comme si tu voulais qu'on fasse tes devoirs.
Ça ne veut rien dire ! C'est quoi des modèles gratuits ? Selon ce que tu entends alors facebook et google aussi c'est du modèle gratuit ; et on n'est plus du tout dans le libre/oss du coup.
(Vu que les questions du journal était déjà incompréhensibles c'est dans le ton)
on va créer des packs d'assets qui seront eux aussi sous licence libre
Ça c'est super !
on aimerait proposer des jeux-tutoriels
Et ils seraient libres du coup ?
Par exemple je n'ai pas trouvé les sources (code/assets) de Hunt The Yeti. Est-ce que vous n'avez pas jugé utile de les fournir sachant que Superpowers n'est lui-même pas encore libre (et que du coup elles le soient à l'avenir), ou bien est-ce une volonté délibérée de le laisser fermé ?
Personnellement, je ne suis pas convaincu qu'on trouverait assez de monde intéressé à payer pour ouvrir le code d'un jeu vidéo commercial
La question est intéressante, et je me la pose aussi.
La situation était assez différente certes, mais il y a plus de 10 ans quand la communauté a du réunir 100K $ pour libérer Blender, cela s'est fait rapidement.
Plus proche de nous, The Open Bundle n'a pas eu de difficulté à atteindre son objectifs financier pour libérer principalement des assets, de qualité.
À côté de ça, des exemple de libération d'un jeu contre rémunération je n'en vois pas, du coup difficile de savoir. Warzone 2100 a été libéré sans contrepartie et a réunit une petite communauté qui l'a bien amélioré ; c'était vraiment cool de la part de l'éditeur et du studio de dev, mais on ne sait pas quelle somme d'argent la communauté aurait réuni si la libération avait été payante.
Une première étape serait de libérer (si un montant est atteint) un petit jeu qui aurait déjà été amorti par ses ventes (donc on sait que c'est un jeu attirant) quand il commence à moins bien se vendre par exemple. Il n'y aurait pas grand chose à perdre, puisque ce sont les créateurs qui fixent la barre à atteindre. Évidemment c'est quand même complexe, puisque j'imagine qu'un montant abusif pourrait décourager des gens ("ils sont trop gourmands, la campagne va droit dans le mur") qui aurait donné sans ça ; ce qui rendrait un échec de la campagne difficile à analyser ; mais encore une fois il n'y aurait rien à perdre.
Je suis allé tester les deux jeux faits lors de game jam et j'ai vraiment bien aimé ; en particulier j'aime beaucoup le travail graphique sur vos jeux (ces 2 là ainsi que les autres qu'ont voit sur votre blog).
Quand on voit le succès de Unity et de GameMaker, qui font tourner pas mal des très bons jeux indépendants des dernières années, une initiative comme la vôtre (à savoir de faire une plateforme libre) est vraiment réjouissante. Donc félicitation pour le travail accompli, et bon courage pour la suite !
En revanche, j'ai une question qui me taraude. Autant avoir une plateforme libre c'est super, autant avoir en plus des jeux libres, ben ça serait encore mieux. Visiblement vous avez le talent pour faire des jeux, donc ma question est : avez-vous aussi l'envie de faire des jeux libres (code + assets), ou bien vos intentions sont de ne libérer que SuperPowers même dans un avenir lointain ??
Attention, je ne suis pas en train de réclamer des jeux gratuits : je serai vraiment ravi de payer pour avoir des jeux libres, sachant que cela pourrait dans les faits se faire de diverses manières :
payer pour libérer un jeu proprio fini.
payer pour libérer les assets proprios d'un jeu avec un code libre.
financer (via financement participatif) le développement d'un jeu libre (avec évidemment les réserves classiques de faisabilité et cie bien sûr).
libération d'un jeu lorsque sa période de commercialisation est finie.
Le programme en langage assembleur est transformé en programme équivalent en langage machine : c'est bien une compilation. Une compilation triviale certes, une compilation qui laisse peu de place à l'imagination certes, mais une compilation quand même.
L'avantage des langages compilés (comme C, Ada ou Fortran) est qu'ils ont une sorte de parfum d'éternité.
Oui je comprends ; maintenant cette "éternité" n'est atteignable que pour les logiciels n'interagissant que peu avec le système (comme ici, lire et écrire des fichiers principalement). Ça représente certes bon nombre de nos logiciels d'unixien, mais heureusement qu'on ne se contente de cette classe de logiciel. Et à partir du moment on va se se lier à GTK, Qt, libXML, openSSL, openGL… on peut être certain que 15 ans après notre binaire laissé sur une disquette au fond d'un tiroir ne va plus tourner. C'est frustrant je le concède mais l'idée de logiciels évoluant sans cesse tels des formes de vie me parait tout aussi intéressante que des logiciel figés dans le marbre (ce qui ne m'empêche pas de comprendre votre motivation de ne pas vouloir corriger votre logiciel tous les 2 mois hein).
En revanche pour NB, autant il ne me viendrait pas à l'idée de coder un logiciel en Bash (déjà qu'un script de 3 lignes…), autant je m'interroge : vos problèmes venaient-ils de changements dans Bash ou dans NB lui-même (auquel cas le langage n'a rien a voir là dedans) ?
Attention je ne remettais pas en question le choix du langage ; même si le choix est des plus singuliers, ce n'était pas l'objet de mon commentaire.
Je vois que vous avez surtout l'humilité de l'autodidacte, car je vous rassure, les professionnels ont aussi beaucoup de lacunes !! Des tas de pros se reposent sur ce qu'ils ont appris quand ils avaient 20 ans sans remettre en cause leurs connaissances, donc je n'ai souci avec quelqu'un qui se remet à coder a 50 ans ! :)
Sincèrement, je ne savais pas que Pascal, Lisp (avec SBCL), Ocaml, Haskell, Eiffel pouvaient être compilés statiquement (et sans runtime ?) sur Linux.
Pour le runtime, Ocaml, Haskell ou Lisp qui utilisent un Garbage Collector ont un runtime ; en revanche si j'ai bien compris c'est plus le fait que compiler en statique qui vous intéresse plutôt que l'absence de runtime (mais j'ai lu en diagonale), et pour le coup je ne saurais pas vous dire ce qu'il en est (mais Ocaml générant du C, j'imagine que cela doit être possible).
Concernant le choix du langage capable de générer un binaire, la liste était très courte: il n’y avait pas de Basic (à l’époque) pour Linux ; restait le langage C, Ada et Fortran.
Ces dernières années, j'ai l'impression qu'il y a un regain d’intérêt pour les langages qui compilent du natif (Rust, Go, D, Nim…), et c'est plutôt excitant de voir ce que ça va donner dans l'écosystème du Web. Mais même en 2009 (et même 2006) il y avait déjà bien d'autres langages capables de générer un binaire: C++, Pascal, Lisp (avec SBCL), Ocaml, Haskell, Eiffel…
Pour Stallman, l'important est l'accès aux sources, afin de garantir à l'utilisateur une certaine sérénité. D'où l'obligation de donner accès aux sources si on le demande.
Non l'important c'est bien la liberté ; c'est pour ça que ça s'appelle "Free software" et pas "Accessible source code software". L'accessibilité n'est qu'une des nombreuses conditions techniques qui permettent les 4 libertés. D'ailleurs le code de UE4 est accessible ; il est très loin d'être libre pour autant.
Avec la licence BSD c'est un peu l'inverse : chacun fait ce qu'il veut.
C'est plus libre, mais personne n'a de garanties.
Comme je l'ai dit, on peut tout à fait penser que la licence BSD est plus libre que la GPL. Ça revient à se poser la question "la liberté d'enlever la liberté est-elle une bonne chose ?". Mais dans tous les cas, quelle que soit la licence entre BSD et GPL qui apporte le plus de liberté (je rappelle que pour la GPL, le but est la liberté des utilisateurs finaux avant tout) ça ne remet pas en cause l'intention de Stallman.
Par exemple, à mon avis, brider le design de GCC afin de mettre des bâtons dans les roues au logiciel propriétaire était stupide, car cela a aussi privé le libre d'un compilateur qui aurait pu être bien meilleur. Comme je le dis souvent, l'enfer est pavé de bonnes intentions.
Et dans bien des cas la LGPL est là pour que tout le monde soit content.
Il me semblait que l'open source s'était les avantages techniques de libre mais sans la philosophie
Alors les choses peuvent être résumées, dans un certain sens, de cette manière, mais encore faut-il comprendre ce que ça veut dire derrière.
Pour Richard Stallman, le créateur du terme "Free software" l'important c'est la liberté (des utilisateurs du logiciel), qui a été formalisée par les 4 libertés fondamentales du logiciel.
Pour les créateurs de l'"Open source", Bruce Perens et Eric S. Raymond, l'important est la saine collaboration afin d'obtenir de bons logiciels (cf le texte "La cathédrale et le bazar"). Cette idée est formalisée par les 10 points qui font qu'un logiciel est Open Source, et qui va donc bien plus loin que pouvoir voir le code source.
Au final, les licences considérées comme libres (par la FSF classiquement, mais Debian a par exemple des critères encore plus stricts), qu'elles soit héréditaires/contaminantes (GPL, LGPL, AGPL, CC-SA…) ou non (BSD, MIT, CC-BY…) sont aussi considérées comme Open Source par l'Open Source Initiative. Il existe certes des licences Open Source mais pas libres, mais c'est de l'ordre de l'exception, en générale cela recouvre les mêmes licences. Du coup, l'UnrealEngine4 qui ne peut pas être considéré comme libre, ne peut pas être Open Source.
Donc un projet peut en pratique être indifféremment être vu comme libre ou open source. Maintenant si ses contributeurs parlent plus de libre ou d'open source, cela peut indiquer en effet leur vision des choses (philosophiques ou pragmatiques), mais il faut bien voir que ce n'est pas blanc ou noir ; un pragmatique peut envoyer un patch à un projet qui se défini comme libre, un libriste peut contribué à un projet qui se défini comme Open source. Et bien des projets ne se positionnent pas spécialement.
genre llvm/clang ou encore les licences BSD
Et pour le coup là ça ne veut donc pas dire grand chose. Parmi les gens qui choisissent une licence BSD, certains le font par pragmatisme (ex: être utilisé par plein de gens et recevoir des patches), d'autres par philosophie (certains pensent que BSD est plus libre que GPL, mais c'est un autre débat) ; les 2 raisons ne sont bien évidemment pas mutuellement exclusives.
Pour LLVM, même si Apple en est un gros contributeur (et que cette entreprise de manière générale ne peut être considérée comme libriste) :
il n'y a pas que Apple qui contribue.
un libriste peut tout à fait être embauché par Apple pour bosser uniquement sur ce projet.
Pour le coup, dire que LLVM est plus open source que libre dans l'approche n'a pas vraiment de sens ; des tas de gens avec des desseins différents bossent dessus.
Non. "Open source" correspond à une définition précise, à savoir les 10 points spécifiés par l'Open Source Initiative, qui en pratique recouvrent à peu prés la même chose que les 4 libertés du logiciel libre.
Là on se rapproche du concept plus nébuleux de "shared source" de Microsoft.
Personnellement je pense le contraire : utiliser un langage multi-paradigmes est une mauvaise idée
Pour le coup OCaml (vers lequel tu semblais attiré, et c'est très bien) est multi-paradigme. En pratique l'approche fonctionnelle est privilégiée, mais le multi-paradigme n'est pas un mal en soit. Au contraire selon les problèmes un paradigme s'en sort mieux qu'un autre.
Bon c'est un projet de recherche et je doute que ce soit une bonne idée en production, mais ça me semblait intéressant comme projet.
Sinon si c'est l'immuabilité qui t'intéresse (ce n'est pas le seul avantage du fonctionnel), alors Rust est un candidat intéressant. Si on oublie que la 1.0 n'est pas encore sortie (mais c'est pour bientôt) il a l'avantage par rapport à OCaml de ne pas avoir de GC et d'avoir des threads qui s'exécutent en parallèle ; en revanche le fait de se soucier des références (emprunt, temps de vie) rend le code plus complexe à écrire.
Ça n'a pas de sens ; dans un système par comptage de référence, un cycle entraîne une fuite mémoire. Et il faut justement un GC pour détecter automatiquement ces cycles (si notre cerveau ne l'a pas fait en lisant le code donc). Donc si tu veux un crash il faut lancer quand même le GC, mais crasher plutôt que libérer la mémoire.
En revanche tu peux:
réactiver le GC lorsque c'est intelligent, genre entre les niveaux.
activer le GC à la demande quand tu es en debug mode, et voir s'il a collecté des choses (et donc si ton code casse bien les cycles).
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 8.
Je n'ai jamais prétendu le contraire ; C++ évolue sans casser la compatibilité et c'est très bien au vue du nombre de logiciels écrits en C++. Mais du coup C++ se traînera toujours certains boulets, malgré toutes ses évolutions.
Rust apporte une solution à bon nombre de ces boulets ; ça ne veut pas dire qu'il est parfait. On peut même être sûr que s'il est toujours utilisé dans 30 ans (ce qui n'est pas gagné encore une fois), on aura largement eu le temps de lui déceler des tas de boulet à lui aussi.
Après tu as tout à fait le droit de douter de l'intérêt de Rust. Mais les arguments à base de "C++ c'est utilisé depuis 30 ans dans des millions de logiciels nananère" ne sont pas franchement très intéressants. Oui c'est vrai la popularité de C++ est un avantage sur tous pleins d'aspects ; mais bon ici on est sur linuxfr, on en connaît plein des logiciels géniaux qui ne sont pas hyper connus, mais qui arrivent à vivre depuis longtemps (tout le monde ici connaît Blender , pourtant c'est loin d'être le cas de tous les graphistes).
Je n'ai vu personne sur le thread dire qu'il fallait réécrire tous les logiciels C++ en Rust ; et pour une bonne raison c'est que ça serait stupide. En revanche pour un nouveau logiciel (et des logiciels libres qui manquent ben y en a des tas), cela peut être un choix intéressant.
En fait depuis le début j'ai l'impression que quand les gens écrivent "Rust est peut-être le C++ du futur", tu lis "le C++ c'est de la merde, et les devs C++ sont des idiots" : ce n'est absolument pas le cas ! Les créateurs de Rust ont beaucoup pratiqué le C++, l'aiment et suivent de près ses évolutions ; ils sont confrontés aux mêmes problèmes, et les solutions du C++ sont très réfléchies.
# Spring
Posté par GuieA_7 (site web personnel) . En réponse au journal OpenRTS, un moteur de jeux-vidéo open-source en Java. Évalué à 2.
Déjà bravo pour le travail accompli ; il y a un mois j'avais vu passé le projet sur FreeGamer, et la vidéo de l'éditeur de carte est vraiment très sympa.
En revanche je m'interroge : y a-t-il des fonctionnalités qui vous différencient de Spring ?
Par exemple je ne pense pas que Spring permette de faire autres chose que des classiques maps rectangulaires ; alors que dans le monde propriétaire j'aime beaucoup (sans y avoir jouer) Planetary annihilation qui propose des maps qui sont des systèmes solaires avec de petites planètes ! Mais pour le coup, OpenRTS m'a l'air tout aussi classique (c'est juste une fonctionnalité qui me parait intéressante, mais il y a sûrement moyen d'innover sur d'autres fronts).
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 4.
Dans mon journal sur la version 0.7 je comparais déjà Rust à Go (et j'expliquais en quoi ces langages sont très différents sur bien des plans).
À côté de ça Rust a vraiment une philosophie proche de C++ ("What you don’t use, you don’t pay for") ; par exemple voir ici une explication très intéressante sur les traits.
Et sur le reddit de Rust, les clashes avec Go et C++ sont tous les deux très courants.
Mouais ils ont écrit Go pour leur propre usage (comme Mozilla), et au bout d'un certain temps à essayer de le 'vendre' aux développeurs C++ se sont aperçus que c'est plutôt les dev Python/Ruby que ça intéressait ; ce n'est pas une critique en soit, mais de là en faire des génies du marketing… Bien des réussites de l'industrie étaient complètement inattendues, et aujourd'hui mis à part les géants que sont Microsoft (avec C#) ou Apple (avec Objective-C et Swift), aucune entreprise n'est capable d'imposer un langage ; les autres ben ils essaient de faire de leur mieux et parfois c'est un succès. Mais bon on peut aussi dire que C++ c'est le mieux que pourra faire l'humanité et donc on arrête de chercher tout de suite.
C'est vrai, quelques langages se taillent la part du lion, et les autres se retrouvent bien souvent à vivoter (au mieux). D'un autre côté on a aussi les couples C#/Java et Python/Ruby, dans lesquelles des langages quand même très proches évoluent en parallèle (restant concurrents) et ont tous des communautés suffisamment dynamiques pour trouver un peu tout ce qu'on veut en terme de bibliothèques.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 10.
Le potentiel c'est quand même important ; Javascript (ou Python/Go/Java/… peu importe) ne pourront jamais être aussi rapides (ou léger en mémoire) que C/C++, car leur sémantique les en empêchera toujours. À côté de ça, les performances de ces différents langages ont largement eu le temps de s'améliorer depuis leur 1.0 ; Go par exemple était en 1.0 il n'y a pas si longtemps, et les performances n'étaient pas terribles.
Il reste, je crois, encore pas mal d'optimisations assez faciles (le code de rustc n'étant pas forcément génial), le plus important ayant été de stabiliser la sémantique du langage, afin de s'assurer par exemple que les évolutions futures soient réalisables sans tout casser. En effet le concept des références/temps de vie est différent de ce qu'on connaît ailleurs, et nécessite souvent de concevoir son code de manière différente ; il était important que cette nouvelle approche ne soit pas globalement une régression.
Il n'y a pas si longtemps par exemple un simple 'Hello world' en Rust prenait plusieurs Mo (car il embarquait toute la lib standard, un truc comme ça).
Évidemment aller chercher le potentiel demandera du temps et des ressources, et rien ne garanti qu'il sera atteint un jour. Les résultats actuels sont déjà très intéressants, on peut donc faire preuve d'un certain optimisme !
Pas forcément. Au alentours de la 0.7, je me rappelle que rustc était déjà capable dans certains cas d’émettre des informations d'aliasing pour LLVM (et qui permettent des optimisations), et qui ne pouvaient pas être émises par du code C++ (le langage n'ayant pas la sémantique adéquate).
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Non, ce n'est pas pour ça : http://www.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/
En gros, la rouille un champignon robuste, distribuée et parallèle.
[^] # Re: .
Posté par GuieA_7 (site web personnel) . En réponse au sondage Mon processeur préféré ?. Évalué à 4.
Mouais bof.
Tu prends 2 minutes (sûrement moins en fait sur n'importe quelle distro linux) pour installer pygame (par exemple), et pareil en 10 lignes tu fais une fenêtre et tu affiches un sprite. En quelques lignes tu peux le faire bouger avec les touches du clavier ; en 2 lignes tu joues une musique de fond, et 20 lignes tu fais un système basique de lecture/écriture de sauvegarde ; etc…
Que tu aies découvert les joies de la programmation avec l'assembleur, très bien. Je suis aussi passionné que toi, mais moi j'ai commencé par le BASIC (et j'ai fait du langage assembleur plus tard, en école d'ingénieur). Et les jeunes d'aujourd'hui, ils découvriront leur passion avec encore autre chose, peu importe.
# Verrou global
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche OpenBSD 5.7 « Blues Brothers ». Évalué à 2.
Dans mes souvenirs qu'il y a quelques années, les développeurs d'OpenBSD avaient choisit que garder le verrou global, car mettre des verrous plus fins, en rendant le code plus complexe (et donc plus dur à auditer d'un point de vue sécurité) ne valait pas le coup dans leur optique de sécurité avant tout.
Qu'est ce qui a changé depuis ? Les problèmes de performances, avec la présence de multi-core dans la machine de Mme Michu, ont-ils rendu à présent le compromis intéressant ? Sont-ils plus nombreux pour pouvoir maintenant auditer un code plus complexe ? Ont-ils juste changé d'avis ?
[^] # Re: À mort les SS2I
Posté par GuieA_7 (site web personnel) . En réponse au journal sous-developpeurs-SSII. Évalué à 2.
Pourtant c'est très possible ; pas à Paris j'imagine, mais en province si (je suis à Marseille). J'ai été au SMIC pendant plusieurs années (monter sa boite c'est travailler plus pour gagner moins :) ), et oui économiser 250€ par mois était habituel :
# Salve de questions
Posté par GuieA_7 (site web personnel) . En réponse au journal Présentation du projet (film d'animation) ZeMarmot et appel à musiciens. Évalué à 1.
Tout d'abord je tiens à dire que je trouve votre projet très intéressant. En revanche, il soulève pas mal d'interrogations chez moi.
[^] # Re: Hum...
Posté par GuieA_7 (site web personnel) . En réponse au journal Code libre/oss : offre proprio ?. Évalué à 1.
Si tu voulais dire qu'ils développent entre autre du logiciel libre (et gratuit), ben il fallait le dire. Mais bon c'était plus facile de balancer 3 questions absconses sans début de réponse, comme si tu voulais qu'on fasse tes devoirs.
[^] # Re: Hum...
Posté par GuieA_7 (site web personnel) . En réponse au journal Code libre/oss : offre proprio ?. Évalué à 2.
Ça ne veut rien dire ! C'est quoi des modèles gratuits ? Selon ce que tu entends alors facebook et google aussi c'est du modèle gratuit ; et on n'est plus du tout dans le libre/oss du coup.
(Vu que les questions du journal était déjà incompréhensibles c'est dans le ton)
[^] # Re: Bravo + question
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Sparklin Labs: Financement participatif pour Superpowers. Évalué à 1.
Ça c'est super !
Et ils seraient libres du coup ?
Par exemple je n'ai pas trouvé les sources (code/assets) de Hunt The Yeti. Est-ce que vous n'avez pas jugé utile de les fournir sachant que Superpowers n'est lui-même pas encore libre (et que du coup elles le soient à l'avenir), ou bien est-ce une volonté délibérée de le laisser fermé ?
La question est intéressante, et je me la pose aussi.
À côté de ça, des exemple de libération d'un jeu contre rémunération je n'en vois pas, du coup difficile de savoir. Warzone 2100 a été libéré sans contrepartie et a réunit une petite communauté qui l'a bien amélioré ; c'était vraiment cool de la part de l'éditeur et du studio de dev, mais on ne sait pas quelle somme d'argent la communauté aurait réuni si la libération avait été payante.
Une première étape serait de libérer (si un montant est atteint) un petit jeu qui aurait déjà été amorti par ses ventes (donc on sait que c'est un jeu attirant) quand il commence à moins bien se vendre par exemple. Il n'y aurait pas grand chose à perdre, puisque ce sont les créateurs qui fixent la barre à atteindre. Évidemment c'est quand même complexe, puisque j'imagine qu'un montant abusif pourrait décourager des gens ("ils sont trop gourmands, la campagne va droit dans le mur") qui aurait donné sans ça ; ce qui rendrait un échec de la campagne difficile à analyser ; mais encore une fois il n'y aurait rien à perdre.
# Bravo + question
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Sparklin Labs: Financement participatif pour Superpowers. Évalué à 4.
Je suis allé tester les deux jeux faits lors de game jam et j'ai vraiment bien aimé ; en particulier j'aime beaucoup le travail graphique sur vos jeux (ces 2 là ainsi que les autres qu'ont voit sur votre blog).
Quand on voit le succès de Unity et de GameMaker, qui font tourner pas mal des très bons jeux indépendants des dernières années, une initiative comme la vôtre (à savoir de faire une plateforme libre) est vraiment réjouissante. Donc félicitation pour le travail accompli, et bon courage pour la suite !
En revanche, j'ai une question qui me taraude. Autant avoir une plateforme libre c'est super, autant avoir en plus des jeux libres, ben ça serait encore mieux. Visiblement vous avez le talent pour faire des jeux, donc ma question est : avez-vous aussi l'envie de faire des jeux libres (code + assets), ou bien vos intentions sont de ne libérer que SuperPowers même dans un avenir lointain ??
Attention, je ne suis pas en train de réclamer des jeux gratuits : je serai vraiment ravi de payer pour avoir des jeux libres, sachant que cela pourrait dans les faits se faire de diverses manières :
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Moteur de blog fBlog. Évalué à 1.
Le programme en langage assembleur est transformé en programme équivalent en langage machine : c'est bien une compilation. Une compilation triviale certes, une compilation qui laisse peu de place à l'imagination certes, mais une compilation quand même.
[^] # Re: Langages
Posté par GuieA_7 (site web personnel) . En réponse au journal fBlog. Évalué à 1.
Oui je comprends ; maintenant cette "éternité" n'est atteignable que pour les logiciels n'interagissant que peu avec le système (comme ici, lire et écrire des fichiers principalement). Ça représente certes bon nombre de nos logiciels d'unixien, mais heureusement qu'on ne se contente de cette classe de logiciel. Et à partir du moment on va se se lier à GTK, Qt, libXML, openSSL, openGL… on peut être certain que 15 ans après notre binaire laissé sur une disquette au fond d'un tiroir ne va plus tourner. C'est frustrant je le concède mais l'idée de logiciels évoluant sans cesse tels des formes de vie me parait tout aussi intéressante que des logiciel figés dans le marbre (ce qui ne m'empêche pas de comprendre votre motivation de ne pas vouloir corriger votre logiciel tous les 2 mois hein).
En revanche pour NB, autant il ne me viendrait pas à l'idée de coder un logiciel en Bash (déjà qu'un script de 3 lignes…), autant je m'interroge : vos problèmes venaient-ils de changements dans Bash ou dans NB lui-même (auquel cas le langage n'a rien a voir là dedans) ?
[^] # Re: Langages
Posté par GuieA_7 (site web personnel) . En réponse au journal fBlog. Évalué à 3.
Attention je ne remettais pas en question le choix du langage ; même si le choix est des plus singuliers, ce n'était pas l'objet de mon commentaire.
Je vois que vous avez surtout l'humilité de l'autodidacte, car je vous rassure, les professionnels ont aussi beaucoup de lacunes !! Des tas de pros se reposent sur ce qu'ils ont appris quand ils avaient 20 ans sans remettre en cause leurs connaissances, donc je n'ai souci avec quelqu'un qui se remet à coder a 50 ans ! :)
Pour le runtime, Ocaml, Haskell ou Lisp qui utilisent un Garbage Collector ont un runtime ; en revanche si j'ai bien compris c'est plus le fait que compiler en statique qui vous intéresse plutôt que l'absence de runtime (mais j'ai lu en diagonale), et pour le coup je ne saurais pas vous dire ce qu'il en est (mais Ocaml générant du C, j'imagine que cela doit être possible).
# Langages
Posté par GuieA_7 (site web personnel) . En réponse au journal fBlog. Évalué à 3.
Ces dernières années, j'ai l'impression qu'il y a un regain d’intérêt pour les langages qui compilent du natif (Rust, Go, D, Nim…), et c'est plutôt excitant de voir ce que ça va donner dans l'écosystème du Web. Mais même en 2009 (et même 2006) il y avait déjà bien d'autres langages capables de générer un binaire: C++, Pascal, Lisp (avec SBCL), Ocaml, Haskell, Eiffel…
[^] # Re: L'origine
Posté par GuieA_7 (site web personnel) . En réponse au message Unreal engine gratuit oui ! Libre non ! Mais open source ? . Évalué à 1.
Non l'important c'est bien la liberté ; c'est pour ça que ça s'appelle "Free software" et pas "Accessible source code software". L'accessibilité n'est qu'une des nombreuses conditions techniques qui permettent les 4 libertés. D'ailleurs le code de UE4 est accessible ; il est très loin d'être libre pour autant.
Comme je l'ai dit, on peut tout à fait penser que la licence BSD est plus libre que la GPL. Ça revient à se poser la question "la liberté d'enlever la liberté est-elle une bonne chose ?". Mais dans tous les cas, quelle que soit la licence entre BSD et GPL qui apporte le plus de liberté (je rappelle que pour la GPL, le but est la liberté des utilisateurs finaux avant tout) ça ne remet pas en cause l'intention de Stallman.
Par exemple, à mon avis, brider le design de GCC afin de mettre des bâtons dans les roues au logiciel propriétaire était stupide, car cela a aussi privé le libre d'un compilateur qui aurait pu être bien meilleur. Comme je le dis souvent, l'enfer est pavé de bonnes intentions.
Si seulement :)
[^] # Re: L'origine
Posté par GuieA_7 (site web personnel) . En réponse au message Unreal engine gratuit oui ! Libre non ! Mais open source ? . Évalué à 2.
Alors les choses peuvent être résumées, dans un certain sens, de cette manière, mais encore faut-il comprendre ce que ça veut dire derrière.
Pour Richard Stallman, le créateur du terme "Free software" l'important c'est la liberté (des utilisateurs du logiciel), qui a été formalisée par les 4 libertés fondamentales du logiciel.
Pour les créateurs de l'"Open source", Bruce Perens et Eric S. Raymond, l'important est la saine collaboration afin d'obtenir de bons logiciels (cf le texte "La cathédrale et le bazar"). Cette idée est formalisée par les 10 points qui font qu'un logiciel est Open Source, et qui va donc bien plus loin que pouvoir voir le code source.
Au final, les licences considérées comme libres (par la FSF classiquement, mais Debian a par exemple des critères encore plus stricts), qu'elles soit héréditaires/contaminantes (GPL, LGPL, AGPL, CC-SA…) ou non (BSD, MIT, CC-BY…) sont aussi considérées comme Open Source par l'Open Source Initiative. Il existe certes des licences Open Source mais pas libres, mais c'est de l'ordre de l'exception, en générale cela recouvre les mêmes licences. Du coup, l'UnrealEngine4 qui ne peut pas être considéré comme libre, ne peut pas être Open Source.
Donc un projet peut en pratique être indifféremment être vu comme libre ou open source. Maintenant si ses contributeurs parlent plus de libre ou d'open source, cela peut indiquer en effet leur vision des choses (philosophiques ou pragmatiques), mais il faut bien voir que ce n'est pas blanc ou noir ; un pragmatique peut envoyer un patch à un projet qui se défini comme libre, un libriste peut contribué à un projet qui se défini comme Open source. Et bien des projets ne se positionnent pas spécialement.
Et pour le coup là ça ne veut donc pas dire grand chose. Parmi les gens qui choisissent une licence BSD, certains le font par pragmatisme (ex: être utilisé par plein de gens et recevoir des patches), d'autres par philosophie (certains pensent que BSD est plus libre que GPL, mais c'est un autre débat) ; les 2 raisons ne sont bien évidemment pas mutuellement exclusives.
Pour LLVM, même si Apple en est un gros contributeur (et que cette entreprise de manière générale ne peut être considérée comme libriste) :
Pour le coup, dire que LLVM est plus open source que libre dans l'approche n'a pas vraiment de sens ; des tas de gens avec des desseins différents bossent dessus.
[^] # Re: L'origine
Posté par GuieA_7 (site web personnel) . En réponse au message Unreal engine gratuit oui ! Libre non ! Mais open source ? . Évalué à 4.
Non. "Open source" correspond à une définition précise, à savoir les 10 points spécifiés par l'Open Source Initiative, qui en pratique recouvrent à peu prés la même chose que les 4 libertés du logiciel libre.
Là on se rapproche du concept plus nébuleux de "shared source" de Microsoft.
[^] # Re: Pur ou pas ?
Posté par GuieA_7 (site web personnel) . En réponse au message Langage fonctionnel "bas niveau" (genre C). Évalué à 1.
Pour le coup OCaml (vers lequel tu semblais attiré, et c'est très bien) est multi-paradigme. En pratique l'approche fonctionnelle est privilégiée, mais le multi-paradigme n'est pas un mal en soit. Au contraire selon les problèmes un paradigme s'en sort mieux qu'un autre.
[^] # Re: C
Posté par GuieA_7 (site web personnel) . En réponse au message Langage fonctionnel "bas niveau" (genre C). Évalué à 2.
GCC au moins le fait depuis longtemps, au moins dans les niveaux d'optimisation les plus élevés
(http://stackoverflow.com/questions/490324/how-do-i-check-if-gcc-is-performing-tail-recursion-optimization => apparemment en 03 mais pas en 02). J'imagine que ce n'est pas le seul compilateur à le faire.
Mais bon ça n'en fait évidemment pas un langage fonctionnel.
[^] # Re: Golang
Posté par GuieA_7 (site web personnel) . En réponse au message Langage fonctionnel "bas niveau" (genre C). Évalué à 4.
Un langage expressif ?
# Mezzo
Posté par GuieA_7 (site web personnel) . En réponse au message Langage fonctionnel "bas niveau" (genre C). Évalué à 2.
Leur ambition est d'obtenir quelque chose d'assez proche de Rust (au niveau de la gestion mémoire) me semble-t-il :
http://protz.github.io/mezzo/
https://github.com/protz/mezzo
Bon c'est un projet de recherche et je doute que ce soit une bonne idée en production, mais ça me semblait intéressant comme projet.
Sinon si c'est l'immuabilité qui t'intéresse (ce n'est pas le seul avantage du fonctionnel), alors Rust est un candidat intéressant. Si on oublie que la 1.0 n'est pas encore sortie (mais c'est pour bientôt) il a l'avantage par rapport à OCaml de ne pas avoir de GC et d'avoir des threads qui s'exécutent en parallèle ; en revanche le fait de se soucier des références (emprunt, temps de vie) rend le code plus complexe à écrire.
[^] # Re: Un langage complexe ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Ça n'a pas de sens ; dans un système par comptage de référence, un cycle entraîne une fuite mémoire. Et il faut justement un GC pour détecter automatiquement ces cycles (si notre cerveau ne l'a pas fait en lisant le code donc). Donc si tu veux un crash il faut lancer quand même le GC, mais crasher plutôt que libérer la mémoire.
En revanche tu peux: