[F] [mOved] Mon langage est mieux que le tien - Page 121

squalyl (./3598) :
Quand on programme proprement des périphériques depuis plusieurs threads on utilise des verrous qui empêchent les abominations que cette personne essaye d'éviter.

Sauf que le principe de base du Rust et de t’empêcher dès la compilation de faire du code qui permet des accès concurrent sans verrou. Si ton code compile c'est qu'il ne peut pas y avoir d'accès concurrent.

j'ai jamais vu personne avoir ce problème en plus de 5 ans de mailing list NuttX.

not broken dont fix it toussa

Real Time For the Masses (RTFM)

Il y a même un site dédié (un langage dédié dont l'implémentation Rust s'inspire).

squalyl (./3602) :
j'ai jamais vu personne avoir ce problème en plus de 5 ans de mailing list NuttX.

not broken dont fix it toussa

Je vois tout le temps des gens dire qu'ils n'y a pas de problèmes avec le C/C++, juste des idiots qui ne savent pas l'utiliser.

Mais en même temps ne vois que près de la moitié des CVE des projets C/C++ y compris dans des projets qui sont très surveillés niveau sécurité, sont justement liés a des mauvaise utilisation du langage et ne seraient probablement pas possible avec un langage comme Rust,

Du coup, je ne sais pas trop quoi en conclure si ce n'est que je suis très sceptique quand on me dit qu'il n'y a pas de problème, quel que soit le langage, mais encore plus, en C/C++.

Well, ecrit moi un OS en Rust, ecrit moi un driver en Rust.

Quand je vois la différence du code entre le premier exemple en C et ce "qu'il faut faire en Rust" la complexité du cote est au moins 2x supérieur en Rust. Pas sur que ça soit vraiment plus efficace.

(et je ne parle pas de l'absurdité du dit code, personne ne va ecrire un tel code, ou alors c'est qu'il ne comprend rien a l'embarqué.)

static volatile int* GPIOA_ODR = 0x48000014; void main() { while (1) { *GPIOA_ODR += 1; } } // can preempt `main` void interrupt_handler() { *GPIOA_ODR *= 2; }
vs

const GPIOA: Peripheral<GPIOA> = unsafe { Peripheral::new(0x4800_0000) }; // also generated by svd2rust #[repr(C)] struct GPIOA { moder: MODER, otyper: OTYPER, ospeedr: OSPEEDR, pupdr: PUPDR, idr: IDR, odr: ODR, /* .. */ } fn main() { loop { // critical section: `interrupt_handler` can't preempt this closure interrupt::free(|cs| { GPIOA.borrow(cs).odr.modify(|r, w| w.bits(r.bits() + 1)); }); } } // can preempt `main` fn interrupt_handler() { interrupt::free(|cs| { GPIOA.borrow(cs).odr.modify(|r, w| w.bits(r.bits() * 2)); }); }
(et puis un langage qui viens du monde Web, et dont le nom signifie rouille...)

Oh et il manque toute les parties du genre, comment l'interrupt handler est mis en place, et tout ce qui va avec. Rust supporte-t-il seulement les pointeurs de fonctions?

rust c'est le nirvana qui fait le café, il doit avoir!

uther: moi je me dis que les autres langages sont moins pratiques. Y'a le ADA pour l'embarqué aussi, y'a des libs pour stm32... mais les parties qui accèdent au matos sont en C

Et en dehors du language, ce dont le gars parle peux etre fait avec n'importe quel language, meme le C, meme l'ASM, en gros il ne fait que juste fournir une N-eme lib qui gere le hardware pour toi.

Godzil (./3605) :
Well, ecrit moi un OS en Rust, ecrit moi un driver en Rust.

https://www.redox-os.org/ par exemple

Godzil (./3605) :
Quand je vois la différence du code entre le premier exemple en C et ce "qu'il faut faire en Rust" la complexité du cote est au moins 2x supérieur en Rust. Pas sur que ça soit vraiment plus efficace.

En effet le Rust est plus complexe a mettre en œuvre, parce qu'il essaye de forcer de fournir certaines garantie au programme. C'est vrai que parfois c'est acceptable de préférer la simplicité a la fiabilité, mais il faut quand même faire attention, car on peut finir par ce retrouver avec JavaScript.

On va dire que sur une échelle Simplicité / Correction, on a JavaScript > C > C++ > Java > Rust > Ada. Sachant que ça reste approximatif. Par exemple C/C++ sont un peut particulier, car ils sont simples à utiliser, mais très complexes à bien utiliser.

Godzil (./3605) :
(et puis un langage qui viens du monde Web, et dont le nom signifie rouille...)

Ce n'est pas parce qu'il est soutenu par Mozilla que le langage vient du web. C'est clairement un langage système à comparer au C ou au C++.
Mozilla s'en sert absolument pas pour des sites Web mais pour réécrire des parties de leur moteur Web, qui est actuellement en C++.

Godzil (./3605) :
Oh et il manque toute les parties du genre, comment l'interrupt handler est mis en place, et tout ce qui va avec. Rust supporte-t-il seulement les pointeurs de fonctions?

Bien, sur. C'est le minimum pour un langage système.
Ça serait bien que tu te renseigne sur un langage avant de le critiquer.

squalyl (./3606) :
uther: moi je me dis que les autres langages sont moins pratiques. Y'a le ADA pour l'embarqué aussi, y'a des libs pour stm32... mais les parties qui accèdent au matos sont en C

Rust est clairement quelque part entre ADA et C. Comme le ADA il vise a fournir plus de garantie sur le programme quitte à emmerder un peu le développeur.
Maintenant contrairement au ADA, il est plus poussé vers les garanties à la compilation qu'au Runtime, pour fournir de meilleure performance. Et il permet des échappatoires (block unsafe) qui font qu'il est rarement obligatoire de recourir a un autre langage, si ce n'est pour s'interfacer avec l'existant.

Bien, sur.

C'etait une question et non une affirmation, mais bon.

C'est vrai que parfois c'est acceptable de préférer la simplicité a la fiabilité

Non, la simplicité force indirectement la fiabilité. Moins il y a de code a taper, moins il y a de chance de ce planter. Plus le code est complexe, plus il sera dur a taper correctement et/ou analyser. (KISS principle)

Quand a l'OS, survolé très rapidement (suis au boulot, pas le temps de faire une analyse complete), le depot avec juste le kernel semble etre ecrit qu'en Rust, le reste il y a beaucoup d'ASM, de C et C++.... (le bootloader est 100% en ASM de ce que j'en vois)

Devoir mixer plusieurs languages pour faire un OS, je doit dire que je suis pas fan, C/ASM est deja contraignant, ajouter 2 ou 3 languages de plus rends encore plus complexe pour pas grand chose.

Le C a 46 ans, durant toutes ces annés on a vu et entendu parler de tous un tas de langages qui "font rendre le C si obsolète que plus personne ne l'utilisera". On entendra toujours les même discours dans 30 ans avec le C probablement toujours aussi dominant *sauf* si on a un changement majeur dans la conception des ordinateur.

Non, la simplicité force indirectement la fiabilité. Moins il y a de code a taper, moins il y a de chance de ce planter. Plus le code est complexe, plus il sera dur a taper correctement et/ou analyser. (KISS principle)

KISS est un bon principe : il faut en effet éviter de multiplier les risque d'erreur. Mais attention de ne pas le généraliser bêtement.

Par exemple, il y a moins de code a taper en JavaScript grâce au typage dynamique et aux conversion automatique. Mais ça n'aide pas à la fiabilité, bien au contraire. Ce qui est important de limiter, c'est les causes d'incertitude. Le typage de C++, même s'il est plus verbeux permet de fournir plus de garanties sur les objets que l'on manipule et donc d'améliorer la fiabilité.

De même, la complexité supplémentaire de Rust vient en grande partie du fait que l'on doit manipuler des pointeurs dont le compilateur peut prouver la validité, ce qui est une garantie supplémentaire et non un risque supplémentaire.

https://www.redox-os.org/news/gsoc-self-hosting-final/

et les mecs se précipitent pour porter les outils dont le monde normal a besoin: autotools

Aside from being nearer to self-hosting, porting C software to Redox should be easier now.

I’ve also come to realize that largely following POSIX is important for an OS;

Nothing gives you an appreciation for debuggers like not having one;

ET LES MECS ILS FONT UN OS SANS DEBUGGER

Ca a l'air vachement fun ce langage

C'est tellement de pointe, un debugger est inutile :3

J'avoue que j'avais lu l'article en diagonale (je me suis dit "tiens, enfin des gens qui font un langage en pensant aux contraintes de l'embarqué", sans examiner en détail leurs propositions), je ne pensais pas déclencher une tornade de réactions comme ça

ça fait très ours attaché à ses habitudes comme réaction quand même, n'hésitez pas à trouver des arguments pour que ça ressemble éventuellement à autre chose qu'un échange de croyances religieuses

squalyl (./3611) :
et les mecs se précipitent pour porter les outils dont le monde normal a besoin: autotools

Aside from being nearer to self-hosting, porting C software to Redox should be easier now.

Heu je suis pas sur de voir ce qui est drôle, les autotools sont en effet bien utile si on veut porter des outils C venant de Linux.

squalyl (./3611) :
ET LES MECS ILS FONT UN OS SANS DEBUGGER

Bah il faut bien que ton OS marche suffisamment bien avant de pouvoir faire ton débogueur non?

squalyl (./3611) :
Ca a l'air vachement fun ce langage

Tu mélanges un peu le langage Rust avec le projet Redox OS. La question à la base c'était surtout la faisabilité d'un OS en Rust.
Redox OS est un projet from scratch, dans un langage qui a juste trois ans, fait par des contributeurs qui ne sont pas des experts du domaine des OS, sur leur temps libre. Nul doute que des experts du domaine auraient pu faire mieux, mais ce qu'ils ont fait est quand même déjà pas mal et montre clairement que Rust est viable dans le domaine.

https://bugzilla.redhat.com/show_bug.cgi?id=1510632#c32
Fedora. 6 mois pour corriger un bug. Heureusement, la version suivante est déjà là.
Et comme d'habitude, c'est SELinux qui fait chier.

(plutôt dans le topic Linux, non ?)

Ah oui. J'étais pas convaincu par ma connerie, mais j'avais zappé l'autre topic.

Pourquoi s’entêter a utiliser une distrib que tout le monde sait foireuse et mal foutue?

Zeph (./3614) :
ça fait très ours attaché à ses habitudes comme réaction quand même, n'hésitez pas à trouver des arguments pour que ça ressemble éventuellement à autre chose qu'un échange de croyances religieuses

Concrètement, est-ce que Rust permet de générer des binaires sensiblement aussi efficaces que le C ou C++ ? Fonctionnant sur des architectures aussi limitées ?

Personnellement, j'ai toujours tendance à privilégier les outils qui me donnent un maximum de garanties sur la qualité de mon code, notamment grâce au typage.

Godzil -> en étant un peu moins sectaire, on peut convenir que Fedora est dédié à une certaines frange d'utilisateurs. Elle a aussi ses avantages.

flanker (./3621) :
Concrètement, est-ce que Rust permet de générer des binaires sensiblement aussi efficaces que le C ou C++ ?

Oui, niveau performance c'est de l'ordre du C/C++, d'autant plus que ça repose sur LLVM et que le langage fournit le même genre de contraintes utiles à l'optimisation comme le typage statique. En fait il en fournit même d'avantage mais LLVM n'est pas encore capable de les exploiter.

flanker (./3621) :
Fonctionnant sur des architectures aussi limitées ?

En théorie oui. Maintenant Rust n'a pas encore l'historique du C. Il n'est donc est pas encore supporté par autant d'architectures, même si LLVM aide.

Ok, merci pour ces infos.

Folco: justement je n'entends que des choses négatives a son propos, et ma propre expérience avec les distributions redhat m'ont échaudé a vie. (Slackware était a l’époque plus fiable et bien plus simple a utiliser par exemple!)

malheureusement, il n'y a pas des masses de distrib Linux sérieuse (avec support et versions LTS), et je doute de plus en plus d'Ubuntu…

Debian ? Bon, ok, il n'y a pas à proprement parler de LTS, mais chaque version en est un peu une quand même

Kevin -> j'ai installé Fedora 28, mais je n'ai pas les plugins de Kate, bien que kate-plugins soit installé. Il me manque donc l'intégration de Konsole, que j'utilise beaucoup.

Ma version de Kate est la 17.12.

Une idée d'où chercher le problème ?

Godzil (./3620) :
Pourquoi s’entêter a utiliser une distrib que tout le monde sait foireuse et mal foutue?

SELinux est casse-pieds, mais ça se désactive facilement. À part ça, Fedora n'est pas si mal foutue que ça.

Godzil (./3625) :
Folco: justement je n'entends que des choses négatives a son propos

À tort.

et ma propre expérience avec les distributions redhat m'ont échaudé a vie. (Slackware était a l’époque plus fiable et bien plus simple a utiliser par exemple!)

Slackware plus simple à utiliser que Red Hat???
Il y a toujours eu des mondes en termes de simplicité d'utilisation entre les deux, et absolument pas dans le sens que tu prétends. (Il suffit de lire ce qu'écrivent les journalistes qui ont comparé.)

Folco (./3627) :
Kevin -> j'ai installé Fedora 28, mais je n'ai pas les plugins de Kate, bien que kate-plugins soit installé. Il me manque donc l'intégration de Konsole, que j'utilise beaucoup.

Ma version de Kate est la 17.12.

Une idée d'où chercher le problème ?

Hmmm, pour l'instant non.

Folco (./3627) :
Debian ? Bon, ok, il n'y a pas à proprement parler de LTS, mais chaque version en est un peu une quand même

Ni LTS, ni éditeur derrière sans compter des logiciels antédiluviens

Il y a un bug dans le 68kguide : http://tict.ticalc.org/docs/68kguide.txt
Dans le sommaire, il y a écrit DVIS à la place de DIVS.
C'est où les bug reports ?