[Choix langage] Go / Rust

Le problème exposé dans ce sujet a été résolu.

Que le compilateur soit rapide et que le langage soit fait pour être modulaire, ça n’a rien de particulièrement nouveau comme objectif

Que le langage soit pensé de telle façon que la compilation d’une solution entière se fasse en moins d’une seconde (il ne s’agit pas d’une banale optimisation du compilateur), à l’époque où Go a été créé, il était le seul. Certes aujourd’hui ce n’est plus quelque chose de tellement novateur puisque tous les autres se sont alignés avec plus ou moins de succès, mais il ne faut pas négliger le fait que derrière Go, tu as les travaux de gens qui ont toujours eu une influence considérable sur le domaine, y compris en recherche fondamentale, depuis les années 1960 (Ken Thompson en particulier) : les snober pour le manque d’académisme sur Go a quelque chose de plutôt rigolo.

Il serait judicieux, à mon avis, de se demander comment et pourquoi ces types sont arrivés à ce résultat.

Personne n’a dit que Go était un langage inintéressant à utiliser, ce que j’ai dit c’est qu’il est inintéressant à apprendre.

Et je pense que tu te trompes lourdement à ce sujet.

C’est le seul langage que je connaisse dont les idiomes incitent délibérément à penser la concurrence de cette façon. Et d’expérience, adopter cette façon de penser dans d’autres contextes n’est pas trivial : typiquement l’equipe avec laquelle je bosse a du mal à penser de cette façon en Python, quand bien même la codebase sur laquelle on bosse a inclu ces idiomes dès sa conception (alors que je ne connaissais pas vraiment Go à cette époque… Si c’était à refaire j’aurais probablement poussé Go pour ce projet).

+0 -0

Mouais, soit je passe à côté d’un truc, soit on n’a déjà pas la même vision de la concurrence à la base.

Quand je vois cet exemple, je me dis que ça fait beaucoup de boilerplate pour une simple barrière. Les mécanismes de channels et de goroutines sont pas inintéressants, mais je les trouve pas aussi révolutionnaires que ce que tu fais sentir dans ton message. Peut être que ça dépend du contexte d’utilisation. Par exemple, OK, ça c’est rigolo et élégant, mais j’ai pas le besoin de faire ça. Quand je fais du multi-threading, c’est pour dispatcher des traitements très lourds mais bien séparables (avec potentiellement des shared-state qu’on peut pas se permettre de communiquer) plutôt que d’avoir plein de petits messages dans tous les sens. En ce sens, le modèle de Rust serait beaucoup plus adapté (puisqu’il n’impose pas ce culte de la communication).

+0 -0

Non en vrai, donne toi 2-3 mois pour apprendre à bien utiliser Go.
Puis trouve toi 2-3 autres stages pour maîtriser Rust.

Comment ça j’abuse ? Non je vois pas …

+0 -0

Je t’invite, plutôt qu’à regarder des exemples, à pratiquer : résous des problèmes de concurrence complexes en utilisant les uns puis les autres pour aboutir à des programmes qui fonctionnent et tiennent dans la durée.

En discutant le bout de gras on ne peut qu’être victime du biais qui veut qu’on croit avoir compris les tenants et les aboutissants d’un problème en se contentant d’en observer la solution, et sans vouloir être désagréable, personnellement j’ai autre chose à faire que de passer mon dimanche à combattre ce biais.

(Plus précisément, je suis déjà bien assez occupé à le combattre chez moi pour avoir la foi de le faire chez les autres.)

+1 -0

Puisque le propos a déjà un peu dérivé, je me permet d’en profiter pour poser une question :

Est-ce que quelqu’un connait de bons documents (si possibles facilement lisibles, mais je prendrai ce qui existe) sur la concurrence ou la parallélisation ?

Théoriquement, ça fait parti des choses que je suis censé savoir faire, mais c’est, disons, un peu compliqué…

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte