Belle exemple de double pensée. Tu ne fais que confirmer ce que je dis dans mon journal. Tu autorises la modification de code alors que tu interdis d'utiliser le nom par défaut. Tu utilises des arguments exactement inverse pour l'un et pour l'autre. Pour la marque, tu invoques tous les arguments traditionnels des logiciels propriétaires : le contrôle et la protection. Contre qui ? Contre des utilisateurs potentiellement malveillants. Mais le libre, ça a toujours été la liberté de l'utilisateur et en invoquant ces arguments, tu es clairement dans du non-libre, tu restreint la liberté de tes utilisateurs. Certes, ils peuvent forker et utiliser le code, mais tu leur as enlevé une liberté, celle de garder le nom.
Avec de tels raisonnements, XChat pour Windows n'aurait pas pu exister. Pour rappel, les développeurs de XChat vendaient la version Windows, mais des gens ont compilé une version Windows à partir des sources et la distribuaient sous le même nom. Avec une marque XChat, ils auraient dû l'appeler autrement et il aurait été beaucoup plus difficile de trouver cette version pour Windows. Et pourtant, ils n'ont fait que mettre en pratique les quatre libertés du logiciel libre. Aurait-il fallu contrôler et se protéger de ces gens ? Auraient-ils eu la permission de le faire ?
Tu n'as pas bien compris l'ampleur du problème. Si tu ne protège pas ta marque, cela veux dire que n'importe qui peut redistribuer ton logiciel avec des modifications qui peuvent être indésirables.
Il y a quelques années, quand on reprochait aux linuxiens que les terroristes utilisaient Linux, ça faisait rire tout le monde. Parce que tout le monde comprenait bien que le libre ne protège pas contre des utilisation frauduleuse ou abusive ou je ne sais quoi du code. Mais là, patatras, ça ne devrait plus être possible. Dire qu'on ne veut pas de modifications indésirables sur un logiciel libre, c'est comme dire que les terroristes ne devraient pas utiliser Linux. Ça fait mauvais genre dans les deux cas. Sauf qu'en disant ça, on est clairement dans le non-libre. Si tu permets les modification, tu permets aussi les modifications indésirables.
Les utilisateurs n'auront aucun moyen de savoir si c'est ton logiciel ou un dérivé avec le même nom.
Le ChangeLog, c'est pas fait pour les chiens.
Si tu veux faire ta version du soft, c'est pas un problème dans le libre mais il faut assumer et changer le nom du projet.
Pas du tout. C'est requis par certaines licences mais pas par les plus utilisées (GPL, MIT, BSD). Mettre du droit des marques par dessus, c'est ajouter une restriction qui n'existait pas. La LPPL par exemple requiert un changement de nom, mais elle n'est pas approuvée par l'OSI (qui est quand même très large sur le sujet).
Le fait que RedHat le fasse depuis 20 ans ne contredit en rien mon argument. Parce que RedHat le ferait, il faudrait ne pas interroger cette pratique qui se répand de plus en plus ? Je veux dire, ça tient quand même de l'argument d'autorité là.
J'y vois une protection et une responsabilisation.
Dans toutes les licences libres, il y a une mention qui dit "ça peut faire de la merde", souvent écrite en majuscule. Cette mention n'est pas mise là pour rien.
Comme vu avec The Gimp, si tout est libre, même le logo et le nom, rien n'empêche n'importe quel quidam de les utiliser.
Oui, ça s'appelle le libre.
Typiquement, une nouvelle plateforme d'hébergement de code s'ouvre, le quidam se crée un compte, upload un projet entier et rajoute un adware. Si le nom, le logo et le code sont tous explicitement entièrement libre, aucun recours légal n'est possible. Et si on imagine le pire, le monsieur donne du pognon à google pour monter dans les résultats et le tour est joué.
Oui, et à l'inverse, un contributeur peut arriver, compiler une version avec des options de compil différente qui permettent d'améliorer les perfs sur une archi particulière et mettre ça en téléchargement sur son site en appelant ça The Gimp. L'histoire montre que le cas que je décris est plus courant que celui que tu décris. Et les deux sont permis ou interdits en même temps.
Si demain une grosse boite style adobe, reprend le code de gimp, fait quelques modifications mineurs (par exemple les raccourcis, ajoute des exports vers les fichiers proprios avec du code pourri et mal intégré et volontairement complexe (peut être des bouts d'asm, peut êtres des fonctions qui changent de place pour complexifier la diff-ification), le renomme open manipulation image for cs12, castre une partie des fonctionnalités (pour le bien de l'utilisateur parce que sinon c'est trop complexe) et le distribue gratuitement à tous en donnant un lien vers les sources modifiés, un bon gros tar.gz complet (pas de diff), ils seront toujours dans leur droit, mais est-ce que cela sera "bien", c'est une excellente question. Je n'ai pas de réponse, mais j'aimerais un vraie réponse et pas un truc à l'emporte pièce.
Pour moi, le libre n'a jamais été qu'une question juridique. Donc, oui ils sont dans leur droit, c'est permis, c'est le libre. Et oui c'est de la merde. Maintenant, si on veut lutter contre ça, on ne le fait pas avec les armes de l'ennemi (le droit des marques). Le libre n'a jamais empêché de faire de la merde, mais il autorise à faire des choses sympas et c'est ce qui compte, c'est ce qui a fait son succès avec les années et qui a permis de bâtir l'énorme éco-système qu'on connaît actuellement. Avec du droit des marques, on restreint cette possibilité, on va à l'encontre de l'esprit. Que ce soit copyleft ou pas d'ailleurs.
On peut rapprocher ça du débat sur le NC dans les Creative Commons. Le NC n'est pas libre, personne ne dira le contraire. Et actuellement, si je prend n'importe quel logiciel libre, je peux le vendre tel quel, sans avertir l'auteur, sans même le rétribuer, c'est permis (c'est discutable d'un point de vue moral). Avec un droit des marques sur un logiciel libre, ce n'est plus le cas, je ne peux plus le vendre tel quel. Quelle est la différence entre un NC et le second cas ? Pour moi, aucun. Dans les deux cas, on a ajouté des éléments de propriété intellectuelle qui rendent le truc non-libre.
Des risques juridiques sur l'activité de l'entreprise peuvent faire baisser le prix de l'action (ou le cours d'entrée en bourse), peu importe que ça concerne le libre ou une usine de conserve de poisson.
La SG a fait une analyse hyper rapide de ces transactions pour accuser Kerviel et lui faire porter le chapeau. Ou alors, ils n'en ont rien à foutre et ont charger Kerviel sans preuve.
Raté ! Les moteurs de jeux vidéos ont besoin de pouvoir aller jusque dans les entrailles du système, en particulier sur le point sensible de l'allocation mémoire. Quasiment tous les jeux modernes utilisent plusieurs allocateurs mémoire maison pour optimiser l'utilisation de la mémoire. Juste ce point fait que Rust n'est pas un candidat pour un jeu vidéo d'envergure. Je te renvoie par exemple à la présentation Parallelizing the Naughty Dog Engine Using Fibers où l'orateur montre les modifications qui ont été faite pour la version Remastered de The Last of Us, en particulier sur la mémoire (dans la deuxième partie de la présentation). Je doute très fortement que tout ça soit possible à faire avec Rust.
Rust n'est pas dans un mode de fonctionnement à la C++ ou le comité de normalisation est un "vrai" comité au sens ISO ou autre où là effectivement il y a une lourdeur importante à la participation.
La situation que tu décris n'existe plus depuis quelques années. Tout le monde peut participer, le site du comité explique comment on peut faire une proposition pour le langage ou pour la bibliothèque standard. Ensuite, ces propositions sont discutées dans les réunions auxquelles tout le monde peut participer pour donner son avis. Il existe également des listes de discussions ouvertes à tous sur lesquelles plein de gens font des propositions. Bref, pas de lourdeur, juste un processus qui se rapproche de ce qui se fait ailleurs via des RFC/PEP/WTF, le standard ISO en plus à la fin.
Et ça marche, il y a des choses qui arrivent qui sont proposés par des aficionados du C++, comme A Proposal for the World’s Dumbest Smart Pointer (un pointeur pas intelligent du tout mais qui apporte de la sémantique) ou Source-Code Information Capture (qui permet d'écrire assert comme une fonction sans aucune macro !).
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 !
J'aimerais juste qu'on me décrive Rust sans utiliser le mot C++, qu'on me dise ce que Rust peut faire, qu'on me donne ses fonctionnalités sans forcément devoir comparer à un autre langage dès le premier paragraphe alors que ça n'a pas de sens de le faire.
OK, donc si je comprends bien la page, une fois qu'on a une idée et qu'on a écrit une RFC, il faut un «shepherd» qui est un développeur de confiance, et à la fin, c'est la Core Team qui décide (et comme les liens sont cassés, c'est pas évident de savoir qui est dans la Core Team mais a priori, je dirais qu'il y a beaucoup d'employés Mozilla). Donc un peu d'ouverture mais beaucoup de contrôle de la part de Mozilla quand même.
imposer le français est tout autant colonialiste (breton, basque, corse…)
Non, c'est républicain. La république française est une et indivisible, et les révolutionnaires ont considéré que pour qu'un citoyen puisse participer aux délibérations, tout le monde devait parler la même langue partout sur le territoire : le français. Et on en est encore là (et c'est très bien). La loi Toubon, elle impose le français parce qu'un citoyen français a le droit d'avoir des informations de son administration en langue française et, par conséquent, la langue de travail de l'administration est le français. Juste républicain.
Même sans parler de supplanter, l'envergure de Rust pour l'instant n'est pas très grande, et c'est un euphémisme. Quand on aura un noyau, un jeu AAA, une suite office, un serveur graphique, un environnement de bureau en Rust, là oui on pourra commencer à considérer que Rust a fait ses preuves et rivalise avec C/C++.
Tu me montres où on peut contribuer ? J'ai cherché sur le site de Rust, je n'ai trouvé aucune documentation qui explique comment contribuer directement aux spécifications du langage.
En même temps, s'il n'y a personne d’enthousiaste au début, il n'y a pas de risque que ça prenne.
Ça dépend. Si ça vient combler un vrai manque, ça prend. Si C++ n'avait pas évolué comme il a évolué ces dernières années (et il a bien failli ne jamais repartir après C++03), je pense qu'il y aurait eu de la place pour un remplaçant. Mais sur ce segment, C++ évolue et s'adapte à l'industrie donc pourquoi changer ? Et pourquoi changer pour Rust ?
Depuis le début de la discussion, tu ne semble pas apprécier Rust, serais-tu un développeur C++ inquiet ?
C'est pas que je n'apprécie pas Rust, au mieux ça m'indiffère pour l'instant, je regarde ça de loin. Ce qui m'énerve, c'est qu'on n'arrête pas de comparer Rust à C/C++ alors que ça n'a à peu près rien à voir. Qu'on compare Rust à Go, par exemple, me semble bien plus pertinent. Mais bizarrement, ça n'est jamais fait. 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. Qu'est-ce qui fait dire à Mozilla que Rust va attirer les développeurs C/C++ ? Vu comment les développeurs C/C++ sont traités chaque fois qu'ils critiquent Rust, j'ai envie de dire que c'est mal barré.
Deux langages concurrents très actifs sur la même période, c'est impossible selon toi ?
On ne vit pas dans un monde romantique où chaque langage viendrait présenter ses avantages et où on choisirait le meilleur. 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é.
En lisant tes commentaires, on peut facilement inférer que tu serais près à déduire la qualité d'un langage par sa popularité.
Non, je ne mesure pas la qualité mais l'activité.
Et il est certains que le C et le C++ ne sont LES langages d'hier, d'aujourd'hui et de demain car le monde serait non seulement bien triste et dangereux avec tous ces segfault mais qu'il existe (heureusement) beaucoup d'autres solutions qui ont, eux aussi, des qualités et des défauts. Bref, Rust a autant sa place dans le panel des langages informatiques utilisable comme l'a le C, le COBOL, le Python et l'ATS.
Où est-ce que j'ai dit une telle chose ? J'ai simplement dit que Rust ne sera pas un C/C++ killer, point. Il a le droit d'exister, il fera peut-être une belle carrière, mais il ne supplantera jamais C/C++. Il y a des raisons assez objectives dont on peut discuter mais apparemment, ça n'intéresse personne dans ce thread. Par exemple, le fait que Rust soit plus sûr que C/C++ est un fait, mais ce n'est vraiment pas ça qui fera que Rust remplacera C++ dans plein d'utilisations aujourd'hui.
Mais Rust convient à des problématiques pour lesquelles le C ou le C++ ne conviennent pas, il appartient donc à un marché (d'une importance relative) qui ne semble pas être sous le joug d'un langage semblable.
Nous sommes d'accord. Donc pourquoi vouloir sans cesse comparer Rust à C/C++ ? Ce n'est pas moi hein, c'est le premier paragraphe de la news ! S'ils ne sont pas sur la même cible, alors ça ne sert à rien de les comparer.
Où est-ce que tu as vu que j'interdisais quoi que ce soit à quelqu'un ? Ils ont le droit de claquer leur fric comme ils veulent. Je remets simplement en cause le fait qu'à l'heure actuelle, ce serait un concurrent à C/C++ comme il est dit dans la news. C'est pas interdit par xcomcmdr, j'espère ?
[^] # Re: Un autre exemple
Posté par rewind (Mastodon) . En réponse au journal Quand le libre est un faux nez pour de la vraie propriété intellectuelle. Évalué à 1.
Belle exemple de double pensée. Tu ne fais que confirmer ce que je dis dans mon journal. Tu autorises la modification de code alors que tu interdis d'utiliser le nom par défaut. Tu utilises des arguments exactement inverse pour l'un et pour l'autre. Pour la marque, tu invoques tous les arguments traditionnels des logiciels propriétaires : le contrôle et la protection. Contre qui ? Contre des utilisateurs potentiellement malveillants. Mais le libre, ça a toujours été la liberté de l'utilisateur et en invoquant ces arguments, tu es clairement dans du non-libre, tu restreint la liberté de tes utilisateurs. Certes, ils peuvent forker et utiliser le code, mais tu leur as enlevé une liberté, celle de garder le nom.
Avec de tels raisonnements, XChat pour Windows n'aurait pas pu exister. Pour rappel, les développeurs de XChat vendaient la version Windows, mais des gens ont compilé une version Windows à partir des sources et la distribuaient sous le même nom. Avec une marque XChat, ils auraient dû l'appeler autrement et il aurait été beaucoup plus difficile de trouver cette version pour Windows. Et pourtant, ils n'ont fait que mettre en pratique les quatre libertés du logiciel libre. Aurait-il fallu contrôler et se protéger de ces gens ? Auraient-ils eu la permission de le faire ?
[^] # Re: Il faut protéger son projet, même en libre.
Posté par rewind (Mastodon) . En réponse au journal Quand le libre est un faux nez pour de la vraie propriété intellectuelle. Évalué à 2.
Il y a quelques années, quand on reprochait aux linuxiens que les terroristes utilisaient Linux, ça faisait rire tout le monde. Parce que tout le monde comprenait bien que le libre ne protège pas contre des utilisation frauduleuse ou abusive ou je ne sais quoi du code. Mais là, patatras, ça ne devrait plus être possible. Dire qu'on ne veut pas de modifications indésirables sur un logiciel libre, c'est comme dire que les terroristes ne devraient pas utiliser Linux. Ça fait mauvais genre dans les deux cas. Sauf qu'en disant ça, on est clairement dans le non-libre. Si tu permets les modification, tu permets aussi les modifications indésirables.
Le ChangeLog, c'est pas fait pour les chiens.
Pas du tout. C'est requis par certaines licences mais pas par les plus utilisées (GPL, MIT, BSD). Mettre du droit des marques par dessus, c'est ajouter une restriction qui n'existait pas. La LPPL par exemple requiert un changement de nom, mais elle n'est pas approuvée par l'OSI (qui est quand même très large sur le sujet).
[^] # Re: Retour vers le futur
Posté par rewind (Mastodon) . En réponse au journal Quand le libre est un faux nez pour de la vraie propriété intellectuelle. Évalué à -6.
Le fait que RedHat le fasse depuis 20 ans ne contredit en rien mon argument. Parce que RedHat le ferait, il faudrait ne pas interroger cette pratique qui se répand de plus en plus ? Je veux dire, ça tient quand même de l'argument d'autorité là.
[^] # Re: Responsabilisation
Posté par rewind (Mastodon) . En réponse au journal Quand le libre est un faux nez pour de la vraie propriété intellectuelle. Évalué à -10.
Dans toutes les licences libres, il y a une mention qui dit "ça peut faire de la merde", souvent écrite en majuscule. Cette mention n'est pas mise là pour rien.
[^] # Re: Usurpation
Posté par rewind (Mastodon) . En réponse au journal Quand le libre est un faux nez pour de la vraie propriété intellectuelle. Évalué à -4.
Oui, ça s'appelle le libre.
Oui, et à l'inverse, un contributeur peut arriver, compiler une version avec des options de compil différente qui permettent d'améliorer les perfs sur une archi particulière et mettre ça en téléchargement sur son site en appelant ça The Gimp. L'histoire montre que le cas que je décris est plus courant que celui que tu décris. Et les deux sont permis ou interdits en même temps.
[^] # Re: C'est vrai que c'est abusif comme termes
Posté par rewind (Mastodon) . En réponse au journal Quand le libre est un faux nez pour de la vraie propriété intellectuelle. Évalué à 3.
Il me semble que l'installeur de Debian n'a rien à voir avec celui d'Ubuntu
Debian ne reprend pas les thèmes d'Ubuntu par défaut
???
Debian LTS n'est pas du tout financé par Ubuntu.
Heureusement !
[^] # Re: C'est vrai que c'est abusif comme termes
Posté par rewind (Mastodon) . En réponse au journal Quand le libre est un faux nez pour de la vraie propriété intellectuelle. Évalué à 2.
Pour moi, le libre n'a jamais été qu'une question juridique. Donc, oui ils sont dans leur droit, c'est permis, c'est le libre. Et oui c'est de la merde. Maintenant, si on veut lutter contre ça, on ne le fait pas avec les armes de l'ennemi (le droit des marques). Le libre n'a jamais empêché de faire de la merde, mais il autorise à faire des choses sympas et c'est ce qui compte, c'est ce qui a fait son succès avec les années et qui a permis de bâtir l'énorme éco-système qu'on connaît actuellement. Avec du droit des marques, on restreint cette possibilité, on va à l'encontre de l'esprit. Que ce soit copyleft ou pas d'ailleurs.
On peut rapprocher ça du débat sur le NC dans les Creative Commons. Le NC n'est pas libre, personne ne dira le contraire. Et actuellement, si je prend n'importe quel logiciel libre, je peux le vendre tel quel, sans avertir l'auteur, sans même le rétribuer, c'est permis (c'est discutable d'un point de vue moral). Avec un droit des marques sur un logiciel libre, ce n'est plus le cas, je ne peux plus le vendre tel quel. Quelle est la différence entre un NC et le second cas ? Pour moi, aucun. Dans les deux cas, on a ajouté des éléments de propriété intellectuelle qui rendent le truc non-libre.
[^] # Re: De l'eau dans le gaz ?
Posté par rewind (Mastodon) . En réponse au journal L'Ubuntu Community Council dit au leader de Kubuntu d'arrêter. Évalué à 4.
Des risques juridiques sur l'activité de l'entreprise peuvent faire baisser le prix de l'action (ou le cours d'entrée en bourse), peu importe que ça concerne le libre ou une usine de conserve de poisson.
[^] # Re: De ce que je sache
Posté par rewind (Mastodon) . En réponse au journal de l'utilité des formats ouverts. Évalué à 6.
La SG a fait une analyse hyper rapide de ces transactions pour accuser Kerviel et lui faire porter le chapeau. Ou alors, ils n'en ont rien à foutre et ont charger Kerviel sans preuve.
[^] # Re: Rythme de mise à jour oO
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Même pas. Sortir une nouvelle version et avoir des fonctionnalités ne sont pas nécessairement synonymes.
[^] # Re: Licence des données ?
Posté par rewind (Mastodon) . En réponse au journal OpenRTS, un moteur de jeux-vidéo open-source en Java. Évalué à 3.
Dans ce cas, ce n'est pas libre du tout. Restreindre l'usage rend ces œuvres non-libres.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Raté ! Les moteurs de jeux vidéos ont besoin de pouvoir aller jusque dans les entrailles du système, en particulier sur le point sensible de l'allocation mémoire. Quasiment tous les jeux modernes utilisent plusieurs allocateurs mémoire maison pour optimiser l'utilisation de la mémoire. Juste ce point fait que Rust n'est pas un candidat pour un jeu vidéo d'envergure. Je te renvoie par exemple à la présentation Parallelizing the Naughty Dog Engine Using Fibers où l'orateur montre les modifications qui ont été faite pour la version Remastered de The Last of Us, en particulier sur la mémoire (dans la deuxième partie de la présentation). Je doute très fortement que tout ça soit possible à faire avec Rust.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
La situation que tu décris n'existe plus depuis quelques années. Tout le monde peut participer, le site du comité explique comment on peut faire une proposition pour le langage ou pour la bibliothèque standard. Ensuite, ces propositions sont discutées dans les réunions auxquelles tout le monde peut participer pour donner son avis. Il existe également des listes de discussions ouvertes à tous sur lesquelles plein de gens font des propositions. Bref, pas de lourdeur, juste un processus qui se rapproche de ce qui se fait ailleurs via des RFC/PEP/WTF, le standard ISO en plus à la fin.
Et ça marche, il y a des choses qui arrivent qui sont proposés par des aficionados du C++, comme A Proposal for the World’s Dumbest Smart Pointer (un pointeur pas intelligent du tout mais qui apporte de la sémantique) ou Source-Code Information Capture (qui permet d'écrire
assertcomme une fonction sans aucune macro !).[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à -1.
J'aimerais juste qu'on me décrive Rust sans utiliser le mot C++, qu'on me dise ce que Rust peut faire, qu'on me donne ses fonctionnalités sans forcément devoir comparer à un autre langage dès le premier paragraphe alors que ça n'a pas de sens de le faire.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 1.
C++ évolue encore (et pas qu'un peu), il n'est pas figé dans le marbre jusqu'à la nuit des temps.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à -5.
Il ne faut pas que commencer, il faut continuer dans le temps.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à -2.
OK, donc si je comprends bien la page, une fois qu'on a une idée et qu'on a écrit une RFC, il faut un «shepherd» qui est un développeur de confiance, et à la fin, c'est la Core Team qui décide (et comme les liens sont cassés, c'est pas évident de savoir qui est dans la Core Team mais a priori, je dirais qu'il y a beaucoup d'employés Mozilla). Donc un peu d'ouverture mais beaucoup de contrôle de la part de Mozilla quand même.
[^] # Re: service-public.fr utilise toujours RC4
Posté par rewind (Mastodon) . En réponse à la dépêche Firefox : version 38. Évalué à 7.
Non, c'est républicain. La république française est une et indivisible, et les révolutionnaires ont considéré que pour qu'un citoyen puisse participer aux délibérations, tout le monde devait parler la même langue partout sur le territoire : le français. Et on en est encore là (et c'est très bien). La loi Toubon, elle impose le français parce qu'un citoyen français a le droit d'avoir des informations de son administration en langue française et, par conséquent, la langue de travail de l'administration est le français. Juste républicain.
[^] # Re: Développeur en C++
Posté par rewind (Mastodon) . En réponse à la dépêche Firefox : version 38. Évalué à 3.
Le RAII est présent depuis longtemps en C++ puisqu'il suffit d'avoir un destructeur.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à -5.
Même sans parler de supplanter, l'envergure de Rust pour l'instant n'est pas très grande, et c'est un euphémisme. Quand on aura un noyau, un jeu AAA, une suite office, un serveur graphique, un environnement de bureau en Rust, là oui on pourra commencer à considérer que Rust a fait ses preuves et rivalise avec C/C++.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à -2.
Tu me montres où on peut contribuer ? J'ai cherché sur le site de Rust, je n'ai trouvé aucune documentation qui explique comment contribuer directement aux spécifications du langage.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 1.
Ça dépend. Si ça vient combler un vrai manque, ça prend. Si C++ n'avait pas évolué comme il a évolué ces dernières années (et il a bien failli ne jamais repartir après C++03), je pense qu'il y aurait eu de la place pour un remplaçant. Mais sur ce segment, C++ évolue et s'adapte à l'industrie donc pourquoi changer ? Et pourquoi changer pour Rust ?
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à -2.
C'est pas que je n'apprécie pas Rust, au mieux ça m'indiffère pour l'instant, je regarde ça de loin. Ce qui m'énerve, c'est qu'on n'arrête pas de comparer Rust à C/C++ alors que ça n'a à peu près rien à voir. Qu'on compare Rust à Go, par exemple, me semble bien plus pertinent. Mais bizarrement, ça n'est jamais fait. 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. Qu'est-ce qui fait dire à Mozilla que Rust va attirer les développeurs C/C++ ? Vu comment les développeurs C/C++ sont traités chaque fois qu'ils critiquent Rust, j'ai envie de dire que c'est mal barré.
On ne vit pas dans un monde romantique où chaque langage viendrait présenter ses avantages et où on choisirait le meilleur. 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é.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à -2.
Non, je ne mesure pas la qualité mais l'activité.
Où est-ce que j'ai dit une telle chose ? J'ai simplement dit que Rust ne sera pas un C/C++ killer, point. Il a le droit d'exister, il fera peut-être une belle carrière, mais il ne supplantera jamais C/C++. Il y a des raisons assez objectives dont on peut discuter mais apparemment, ça n'intéresse personne dans ce thread. Par exemple, le fait que Rust soit plus sûr que C/C++ est un fait, mais ce n'est vraiment pas ça qui fera que Rust remplacera C++ dans plein d'utilisations aujourd'hui.
Nous sommes d'accord. Donc pourquoi vouloir sans cesse comparer Rust à C/C++ ? Ce n'est pas moi hein, c'est le premier paragraphe de la news ! S'ils ne sont pas sur la même cible, alors ça ne sert à rien de les comparer.
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par rewind (Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Où est-ce que tu as vu que j'interdisais quoi que ce soit à quelqu'un ? Ils ont le droit de claquer leur fric comme ils veulent. Je remets simplement en cause le fait qu'à l'heure actuelle, ce serait un concurrent à C/C++ comme il est dit dans la news. C'est pas interdit par xcomcmdr, j'espère ?