Pour des softs comme rigrep, l'objectif de l'auteur était clairement d'avoir un grep le plus rapide qui soit et la promesse est tenu en partie par le langage.
Pour les autres, effectivement, dans l'absolu, Rust ne se justifie sans doute pas.
Après, je pense que beaucoup ont tendance à mettre Rust dans la case "bas niveau" à tord.
De ma propre expérience, c'est pas forcément ce qui m'a attiré en premier.
J'ai voulu m'investir dans un langage robuste il y a 4 ans et je l'ai comparé à Go (et à d'autres) à l'époque.
Malgré sa jeunesse, il présentait des vertus sur le typage, pattern matching, programmation fonctionnel qui me semblait bien plus pointus que ceux de Go.
Je ne connais pas l'état actuel de Go mais vu comment ça a évolué niveau Rust : communauté, évol du langage, doc etc... je pense que je ferais le même choix aujourd'hui.
Crystal, que je ne connais que de nom, me parait plus exotique et Occaml (même constat pour Haskell) reste et restera (malgré son âge et sa maturité) un langage de niche plutôt académique.
A titre pro, j'ai jonglé avec Java et C# et je voulais aussi investir dans un langage qui soit moins piloté par une grosse boite donc difficile de privilégier des "Swift", "Kotlin", "Scala", "Go".
( Surtout Google qui n'a aucun scrupule à abandonner une techno dès qu'elle est pas rentable)
Sur l'aspect utilisateur, je trouve aussi qu'avoir des outils cli qui n'utilise pas de GC est un gros avantage.
Sur du linux, on sait très bien qu'on peut avoir un panel de softs très hétérogènes et que ça peut avoir un impact mémoire non négligeable tout cumulé.
Franchement, me dire que sur un serveur, un rpi etc, je vais avoir des cron avec des scripts en python, en nodejs, en scala, en Go etc... et bien je vais me taper n GC qui consomment de la mémoire inutilement.
En C ou en Rust, ça ne sera pas le cas. (sauf cas de fuite, bien entendu)
Je fais sans doute parti de ses dinosaures qui ont du mal à comprendre pourquoi on gaspille tant de mémoire actuellement pour des trucs basiques.
C'est pas du deep learning mais des pauvres scripts et plus c'est populaire et plus ça devrait être insignifiant en impact mémoire, en temps de démarrage etc.
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 9.
Pour des softs comme rigrep, l'objectif de l'auteur était clairement d'avoir un grep le plus rapide qui soit et la promesse est tenu en partie par le langage.
Pour les autres, effectivement, dans l'absolu, Rust ne se justifie sans doute pas.
Après, je pense que beaucoup ont tendance à mettre Rust dans la case "bas niveau" à tord.
De ma propre expérience, c'est pas forcément ce qui m'a attiré en premier.
J'ai voulu m'investir dans un langage robuste il y a 4 ans et je l'ai comparé à Go (et à d'autres) à l'époque.
Malgré sa jeunesse, il présentait des vertus sur le typage, pattern matching, programmation fonctionnel qui me semblait bien plus pointus que ceux de Go.
Je ne connais pas l'état actuel de Go mais vu comment ça a évolué niveau Rust : communauté, évol du langage, doc etc... je pense que je ferais le même choix aujourd'hui.
Crystal, que je ne connais que de nom, me parait plus exotique et Occaml (même constat pour Haskell) reste et restera (malgré son âge et sa maturité) un langage de niche plutôt académique.
A titre pro, j'ai jonglé avec Java et C# et je voulais aussi investir dans un langage qui soit moins piloté par une grosse boite donc difficile de privilégier des "Swift", "Kotlin", "Scala", "Go".
( Surtout Google qui n'a aucun scrupule à abandonner une techno dès qu'elle est pas rentable)
Sur l'aspect utilisateur, je trouve aussi qu'avoir des outils cli qui n'utilise pas de GC est un gros avantage.
Sur du linux, on sait très bien qu'on peut avoir un panel de softs très hétérogènes et que ça peut avoir un impact mémoire non négligeable tout cumulé.
Franchement, me dire que sur un serveur, un rpi etc, je vais avoir des cron avec des scripts en python, en nodejs, en scala, en Go etc... et bien je vais me taper n GC qui consomment de la mémoire inutilement.
En C ou en Rust, ça ne sera pas le cas. (sauf cas de fuite, bien entendu)
Je fais sans doute parti de ses dinosaures qui ont du mal à comprendre pourquoi on gaspille tant de mémoire actuellement pour des trucs basiques.
C'est pas du deep learning mais des pauvres scripts et plus c'est populaire et plus ça devrait être insignifiant en impact mémoire, en temps de démarrage etc.