C'est bien le problème ; c'est souvent une mauvaise idée, mais pas toujours. Aussi il vaut mieux dans un premier temps rester sur quelque chose de haut niveau ; d'autant plus que les langages essaient de garder la compatibilité et donc enlever une fonctionnalité utilisée par plein de programmes n'est pas forcément possible (donc on doit garder une erreur de conception ad vitam). Mais à l'usage on voit bien que des entraves aux contraintes s'avèrent "nécessaires" (puisque les performances peuvent être une fonctionnalité).
Par exemple en Rust les contraintes haut niveau amènent des garanties mémoires qu'on n'a pas en C, et certaines optimisations deviennent alors possibles (le compilateur C ne peut pas prendre certaines décisions optimisantes car il pourrait créer des bugs). Mais à côté de ça on a les blocs unsafe qui permettent dans de rares occasions de faire des optimisations qui seraient vues comme des erreurs par le compilateur. Il est évidemment conseillé de s'en servir le moins possible ; et au final c'est surtout les libs de base (genre les collections) qui vont s'en servir, les programmes classiques s'en passent très bien.
Dans l'absolu tous les langages ont ce genre de déverrouillage des contraintes, vu qu'ils permettent tous de s'interfacer avec du code C. C'est bien souvent pour pouvoir réutiliser du code (ça aurait été faisable dans le langage haut niveau, mais ça prendrait des ressources), mais c'est c'est souvent assumé qu'on va faire une partie critique au niveau performances en C (ou C++, Rust etc...).
[^] # Re: Article de base excellent
Posté par GuieA_7 (site web personnel) . En réponse au journal La programmation concurrente en mode Goto. Évalué à 5.
C'est bien le problème ; c'est souvent une mauvaise idée, mais pas toujours. Aussi il vaut mieux dans un premier temps rester sur quelque chose de haut niveau ; d'autant plus que les langages essaient de garder la compatibilité et donc enlever une fonctionnalité utilisée par plein de programmes n'est pas forcément possible (donc on doit garder une erreur de conception ad vitam). Mais à l'usage on voit bien que des entraves aux contraintes s'avèrent "nécessaires" (puisque les performances peuvent être une fonctionnalité).
Par exemple en Rust les contraintes haut niveau amènent des garanties mémoires qu'on n'a pas en C, et certaines optimisations deviennent alors possibles (le compilateur C ne peut pas prendre certaines décisions optimisantes car il pourrait créer des bugs). Mais à côté de ça on a les blocs
unsafequi permettent dans de rares occasions de faire des optimisations qui seraient vues comme des erreurs par le compilateur. Il est évidemment conseillé de s'en servir le moins possible ; et au final c'est surtout les libs de base (genre les collections) qui vont s'en servir, les programmes classiques s'en passent très bien.Dans l'absolu tous les langages ont ce genre de déverrouillage des contraintes, vu qu'ils permettent tous de s'interfacer avec du code C. C'est bien souvent pour pouvoir réutiliser du code (ça aurait été faisable dans le langage haut niveau, mais ça prendrait des ressources), mais c'est c'est souvent assumé qu'on va faire une partie critique au niveau performances en C (ou C++, Rust etc...).