Du coup éviter de devoir utiliser unsafe, éviter de devoir générer des bindings ?
C'est comme utiliser des FFI dans tout langage. Oui c'est possible, mais ça s'intègre mal à la philosophie et au système de types du langage et ça te fait perdre mine de rien pas mal de temps.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Au contraire de ceux de mes collègues qui restent accrochés à leur écosystème dont d'autres sont propriétaires, tel des naufragés cramponnés à l'épave de leur trirème sabotée, et qui régulièrement se plaignent de tel ou tel plantage, dysfonctionnement, etc.
Pas chez moi.
Poutre, paille, tout ça…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Mais,il y a des tas de gens de qui n'ont pas Linux et pour qui les mises à jour c'est plus compliqué.
Non, c'est encore plus simple.
Ca fait un bail que Firefox et Thunderbird se mettent à jour tout seuls sous Windows (même pas besoin d'un gestionnaire de paquets ni d'interagir avec, comme ces gens qui ont la malchance de ne pas utiliser Windows). :p
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
C'est vrai, perso j'ai jamais eu de problème à cause du GC ou du JIT, en .NET on est vachement bien loti de ce côté là.
Mais en même temps je n'ai jamais écrit de jeu vidéo.
Peut-être en aurais-je en .NET 5 pour émuler un jeu vidéo en étant appelé par la libretro (Native Callable Exports), mais vu que je vise la Megadrive, j'en doute (et au pire je passe à CoreRT ou à Rust).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Le prob du GC c'est qu'il stoppe le monde quand il fait son boulot.
Alors souvent c'est imperceptible, parce que tout est fait pour qu'il soit ultra rapide (on ferait pas des applications de bureau qui tournent à 60 FPS comme avec WPF par exemple sinon. Exemple : Visual Studio), mais bon.
C'est pas super pour un jeu vidéo, par exemple.
L'autre "problème" des langages managés en termes de perfs c'est le JIT (compilation à la volée). Alors y'avait dejà NGEN, ReadyToRun ou autre pour contourner plus ou moins ça mais ça reste partiel.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Avec un ramasse miette, chacune peut avoir des références sur les autres, on ne va pas se préoccuper de la durée de vie des objets, des pointeurs forts ou faibles… Osef on a de la RAM et le GC passera le balai !
Euh, les fuites mémoires à cause d'évènements ou d'objets non-disposés (utilisant des connexions à des bases de données, des ressources réseau, des Span, …), ça arrive et ça fait mal.
C'est l'une des raisons de l'introduction des WeakReference et du Weak Event Pattern en C# il y a fort longtemps.
Techniquement oui, mais Rust est le seul qui prend de l'envol aujourd'hui (Ada, qui l'utilise ?), n'est pas super bizarre à utiliser / mort (Pascal), m'horripile avec ses goroutines et sa syntaxe et son approche (Go).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Oui bah moi je suis bien content qu'un langage tel que Rust soit ENFIN là pour faire du natif, sans me taper toutes les erreurs que le C amène à faire (à moins d'être à moi seul l'équivalent de l'Android Security Team ou celle de MS… ce qui est impossible), et avec toute l'expressivité d'un langage moderne.
Il garantit même que je n'aurais pas de data races. Même C# ne fait pas ça (oui y'a les analyzers de Microsoft mais c'est juste des warnings par défaut et il faut les rajouter sur chaque projet…).
Je vais enfin pouvoir lâcher mon langage préféré (C#, même s'il est open-source), et même s'il tente de corriger le tir (en .NET 5 il est enfin possible d'avoir des points d'entrée pour le natif, ou avec CoreRT on peut carrément le compiler en natif et se passer du GC et de la compilation JIT… mais tout cela est trop expérimental pour le moment).
Le C est mort, vive le C. Vive Rust.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Suffit de voir le succès d'Android en comparaison. Certes il y a Google derrière, mais simplement avoir Google derrière ne suffit pas, il faut que le produit final réponde aux attentes et force est de constater que les distribs Linux desktop n'ont jamais vraiment fait l'affaire.
Windows et Android se sont imposés grâce à la vente liée.
Comme Chrome qui s'est imposé grâce en s'attachant à l'install de n'importe quel freeware.
Merci de ne pas réécrire l'histoire.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Support rust
Posté par xcomcmdr . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 2.
| de la robustesse
Du coup éviter de devoir utiliser
unsafe, éviter de devoir générer des bindings ?C'est comme utiliser des FFI dans tout langage. Oui c'est possible, mais ça s'intègre mal à la philosophie et au système de types du langage et ça te fait perdre mine de rien pas mal de temps.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par xcomcmdr . En réponse au journal Ma vie de joueur : mes retrouvailles avec AMD après 10 ans d'absence.. Évalué à 6.
Qui décide quelles sont ces bonnes pratiques ? Toi peut-être ?
Sales gosses avec leurs jeux vidéos et leurs naintendo !
S'agirait de grandir… S'agirait de grandir…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Servo ? Lent ?
Posté par xcomcmdr . En réponse à la dépêche Résumé des nouveautés de Firefox 81 à 83. Évalué à 2.
Bah, c'est ce qu'il dit.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Je suis d'accord pour dépoussiérer tout ça
Posté par xcomcmdr . En réponse au lien Lennart revient, cette fois-ci il s'attaque à nos homes !!!. Évalué à 5.
Euh si :
https://docs.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-roaming-user-profiles
À la limite sur la version cliente, un petit lien symbolique et c'est fait.
Windows, Linux, déjà (macOS je sais pas, j'imagine que oui).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Je suis d'accord pour dépoussiérer tout ça
Posté par xcomcmdr . En réponse au lien Lennart revient, cette fois-ci il s'attaque à nos homes !!!. Évalué à 6.
Sérieusement, tous ses arguments sont logique.
J'ai toujours trouvé le bidouillage eixstant difficile à suivre et peu logique.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Faut être un peu lucide aussi ... sinon c'est contre productif !
Posté par xcomcmdr . En réponse à la dépêche Solidatech : un programme qui entrave le développement du Libre en milieu associatif. Évalué à 5.
Pas chez moi.
Poutre, paille, tout ça…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: EDF
Posté par xcomcmdr . En réponse au journal Hégémonie et navigateurs. Évalué à 3. Dernière modification le 01 octobre 2020 à 14:33.
Meh, j'ai pas du tout cette expérience. Peut-être parce que j'installe juste le nécessaire ?
Pour le reste il y a chocolatey ou le store MS.
Ce qui bouffe la RAM c'est les navigateurs Web, de loin.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: EDF
Posté par xcomcmdr . En réponse au journal Hégémonie et navigateurs. Évalué à 7.
Non, c'est encore plus simple.
Ca fait un bail que Firefox et Thunderbird se mettent à jour tout seuls sous Windows (même pas besoin d'un gestionnaire de paquets ni d'interagir avec, comme ces gens qui ont la malchance de ne pas utiliser Windows). :p
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Les femmes dans l'informatique
Posté par xcomcmdr . En réponse à la dépêche Hommage à Frances Allen. Évalué à 3. Dernière modification le 09 septembre 2020 à 09:17.
Ca existe pas mal chez les hommes en info de ce que j'ai vu, donc bon…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par xcomcmdr . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 2. Dernière modification le 08 septembre 2020 à 16:41.
Sauf qu'il a vachement moins de temps pour compiler qu'un compilateur AOT, donc d'améliorer les performances.
En revanche, avec de l'AOT tu perds les API de Reflection (voir: CoreRT).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par xcomcmdr . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 0.
C'est vrai, perso j'ai jamais eu de problème à cause du GC ou du JIT, en .NET on est vachement bien loti de ce côté là.
Mais en même temps je n'ai jamais écrit de jeu vidéo.
Peut-être en aurais-je en .NET 5 pour émuler un jeu vidéo en étant appelé par la libretro (Native Callable Exports), mais vu que je vise la Megadrive, j'en doute (et au pire je passe à CoreRT ou à Rust).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par xcomcmdr . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 2.
Le prob du GC c'est qu'il stoppe le monde quand il fait son boulot.
Alors souvent c'est imperceptible, parce que tout est fait pour qu'il soit ultra rapide (on ferait pas des applications de bureau qui tournent à 60 FPS comme avec WPF par exemple sinon. Exemple : Visual Studio), mais bon.
C'est pas super pour un jeu vidéo, par exemple.
L'autre "problème" des langages managés en termes de perfs c'est le JIT (compilation à la volée). Alors y'avait dejà NGEN, ReadyToRun ou autre pour contourner plus ou moins ça mais ça reste partiel.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par xcomcmdr . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 3.
Euh, les fuites mémoires à cause d'évènements ou d'objets non-disposés (utilisant des connexions à des bases de données, des ressources réseau, des Span, …), ça arrive et ça fait mal.
C'est l'une des raisons de l'introduction des WeakReference et du Weak Event Pattern en C# il y a fort longtemps.
(Pour Rust ce commentaire te répond mieux que moi :
https://linuxfr.org/nodes/115151/comments/1823387 ainsi que ses réponses)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par xcomcmdr . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 3. Dernière modification le 06 septembre 2020 à 10:15.
Je ne saurais te répondre, je suis encore en train de découvrir Rust.
Tu aurais un exemple en Java que je pourrais traduire en Rust pour voir ?
(note : je suis pas expert, mais tu as piqué ma curiosité)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par xcomcmdr . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 2.
C'est exactement cette page (The stack and the Heap) qui répond à ta question :
https://doc.rust-lang.org/1.22.0/book/first-edition/the-stack-and-the-heap.html
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: IDE
Posté par xcomcmdr . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 2.
L'extension C/C++, NativeDebug, voire CodeLLDB font l'affait.
Exemple :
https://jason-williams.co.uk/debugging-rust-in-vscode
Ou l'ancienne manière :
https://www.forrestthewoods.com/blog/how-to-debug-rust-with-visual-studio-code/
Dans tous les cas il faut gdb ou un autre débogueur.
Perso ça marchait bien avec l'extension C/C++ et le débogueur de la suite MSVC.
Mais NativeDebug / CodeLLDB avaient l'air d'être plus modernes.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: IDE
Posté par xcomcmdr . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 4.
De ce que j'ai vu, VSCode reste le mieux, avec l'extension officielle. Le débogage fonctionne, aussi.
C'est là dessus que se concentrent les efforts de la communauté si j'ai bien compris.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par xcomcmdr . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 1.
Techniquement oui, mais Rust est le seul qui prend de l'envol aujourd'hui (Ada, qui l'utilise ?), n'est pas super bizarre à utiliser / mort (Pascal), m'horripile avec ses goroutines et sa syntaxe et son approche (Go).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par xcomcmdr . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 8.
Oui bah moi je suis bien content qu'un langage tel que Rust soit ENFIN là pour faire du natif, sans me taper toutes les erreurs que le C amène à faire (à moins d'être à moi seul l'équivalent de l'Android Security Team ou celle de MS… ce qui est impossible), et avec toute l'expressivité d'un langage moderne.
Il garantit même que je n'aurais pas de data races. Même C# ne fait pas ça (oui y'a les analyzers de Microsoft mais c'est juste des warnings par défaut et il faut les rajouter sur chaque projet…).
Je vais enfin pouvoir lâcher mon langage préféré (C#, même s'il est open-source), et même s'il tente de corriger le tir (en .NET 5 il est enfin possible d'avoir des points d'entrée pour le natif, ou avec CoreRT on peut carrément le compiler en natif et se passer du GC et de la compilation JIT… mais tout cela est trop expérimental pour le moment).
Le C est mort, vive le C. Vive Rust.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Vu qu'on de windows j'aurais une question.
Posté par xcomcmdr . En réponse au journal Mieux que Santa Barbara : Munich revient aux logiciels libres. Évalué à 1.
ClearType est en place depuis Windows XP, donc l'aliasing, il est sous X11 dans mon expérience.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Windows n'a pas à s'inquièter
Posté par xcomcmdr . En réponse au journal Mieux que Santa Barbara : Munich revient aux logiciels libres. Évalué à 0.
Source ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est mal parti dans certains endroits ...
Posté par xcomcmdr . En réponse au journal Mieux que Santa Barbara : Munich revient aux logiciels libres. Évalué à -3.
Oh, si on peux plus troller sur TrollFR, où va le monde, je vous le demande ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est mal parti dans certains endroits ...
Posté par xcomcmdr . En réponse au journal Mieux que Santa Barbara : Munich revient aux logiciels libres. Évalué à -8.
Un monde de développeurs pros. Faut croire que c'est pas le cas de tout le monde…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Windows n'a pas à s'inquièter
Posté par xcomcmdr . En réponse au journal Mieux que Santa Barbara : Munich revient aux logiciels libres. Évalué à 7.
Windows et Android se sont imposés grâce à la vente liée.
Comme Chrome qui s'est imposé grâce en s'attachant à l'install de n'importe quel freeware.
Merci de ne pas réécrire l'histoire.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est mal parti dans certains endroits ...
Posté par xcomcmdr . En réponse au journal Mieux que Santa Barbara : Munich revient aux logiciels libres. Évalué à -5. Dernière modification le 18 mai 2020 à 16:06.
Bah écoute, si tu es content c'est le principal.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)