Titre PutaclickSur20.

Il s'agit en réalité d'une n-ème faille de sécurité de Windows, ici via l'utilitaire cmd.exe qui lance une invite de commande, et qui affecte tous les langages de programmation parce que (contrairement à Linux), je cite :

L'API Windows ne fournit qu'une seule chaîne de caractères contenant tous les arguments, laissant au processus créé la responsabilité de les diviser. La plupart des programmes utilisent la chaîne d'exécution standard argv en C, ce qui permet d'obtenir un comportement cohérent en matière de division des arguments. Cependant, cmd.exe possède sa propre logique de découpage des arguments, qui nécessite un échappement personnalisé par la bibliothèque standard Rust [et des autres langages].

Mais comme les communautés qui développent langages libres et interopérables sont de vrais professionnels eux, les langages compensent à la place de Microchiotte ce que Microchiotte aurait dû codé correctement dans Windows...

Bref, Rust est déjà patché. Si vous ne voulez pas être affectés par cette faille de sécurité, travaillez sur un OS digne de ce nom et quittez les boites qui vous forcent à bosser sur OSX ou Windows.

Je découvre un nouveau serveur web pour Rust. Bien plus rapide qu'Actix, son interfaçage avec le code est le même.

Je vais le tester et voir si cela vaut la peine de l'utiliser dans les nouveaux projets.

@Kysofer tu cherchais une implémentation de Twig en Rust mais Twig est inspiré de Jinja2 donc Tera qui est une implémentation de Jinja2 en Rust est compatible avec tes composants Twig écrits pour Pebble 😋 #Cadeau

Du coup nous avons la stack

• Kotlin + Pebble + Jooby + H2DB/PostreSQL pour les projets en clientèle.
• Rust + Tera + Actix + SQLite pour les projets internes.

Pour faire simple, les workspaces de Cargo sont l'équivalent des modules de Maven.

Pour définir une configuration commune à tous les workspaces il faut ajouter ceci dans le Cargo.toml à la racine du projet :

[package]
name = "sotoestevez_medium"
version = "0.1.0"

[workspace]
members = ["add_trait", "beginning_tips", "generify_with_compiler_errors", "modules", "scoped_threads" ]

[workspace.package]
edition = "2021"
authors = ["Soto Estévez <ricardo@sotoestevez.dev>"]
description = "Demos of the articles at https://medium.com/@sotoestevez"
documentation = "https://medium.com/@sotoestevez"
readme = "./README.md"
homepage = "https://www.sotoestevez.dev"
repository = "https://github.com/kriogenia/medium"
license = "MIT OR Apache-2.0"

Puis activer l'héritage dans chaque Cargo.toml des workspaces :

[package]
name = "add_trait"
version = "0.1.0"
edition.workspace = true
authors.workspace = true
description = "Dissecting Rust Traits to Learn Their Secrets"
documentation = "https://betterprogramming.pub/dissecting-rust-traits-to-learn-their-secrets-839845d3d71e"
homepage.workspace = true
repository.workspace = true
license.workspace = true

Cela marche aussi avec les versions des dépendances. Dans le parent on déclare ceci :

[workspace.dependencies]
num = { version = "0.4", default-features = false }
vector2d = "2.2"
rand = "0.8.5"

Et dans les enfants ceci :

[dependencies]
num = { workspace = true, default-features = true }
vector2d.workspace = true

[dev-dependencies]
rand = { workspace = true, features = [ "log" ] }

Je fais beaucoup de Rust ces derniers temps et je cherchais un framework qui puisse m'aider à produire mes requêtes SQL en sachant que je voulais tout sauf une horreur orientée structures comme peut l'être le couple JPA / Hibernate.

Au détour d'un coup de fil, @LapinFeroce me parle de Diesel qui est l'équivalent de Ktorm mais pour Rust. Autant vous dire qu'à la simple lecture de l'exemple de la home page j'étais déjà conquise 😻

Il implémente l'interface log qui est l'équivalent de SLF4J de Java/Kotlin mais pour Rust.

Il a la particularité de pouvoir se configurer directement dans le code en plus de fichier Yaml :

use log::LevelFilter;
use log4rs::append::console::ConsoleAppender;
use log4rs::append::file::FileAppender;
use log4rs::encode::pattern::PatternEncoder;
use log4rs::config::{Appender, Config, Logger, Root};

fn main() {
    let stdout = ConsoleAppender::builder().build();

    let requests = FileAppender::builder()
        .encoder(Box::new(PatternEncoder::new("{d} - {m}{n}")))
        .build("log/requests.log")
        .unwrap();

    let config = Config::builder()
        .appender(Appender::builder().build("stdout", Box::new(stdout)))
        .appender(Appender::builder().build("requests", Box::new(requests)))
        .logger(Logger::builder().build("app::backend::db", LevelFilter::Info))
        .logger(Logger::builder()
            .appender("requests")
            .additive(false)
            .build("app::requests", LevelFilter::Info))
        .build(Root::builder().appender("stdout").build(LevelFilter::Warn))
        .unwrap();

    let handle = log4rs::init_config(config).unwrap();

    // use handle to change logger configuration at runtime
}

Et sa façade log reprend l'API de SLF4J mais sous forme de macros :

let world = "World";
trace!("Hello {}!", world);
debug!("Hello {}!", world);
info!("Hello {}!", world);
warn!("Hello {}!", world);
error!("Hello {}!", world);

À voir pour les performances, mais l'idée de reprendre l'API d'une façade qui a fait ses preuves pour y coller l'implémentation que l'on veut derrière est la bienvenue !

En résumé, la méthode du trait doit prendre en paramètre un

&Fn(X) -> Y

et non un

Fn(X) -> Y

Sinon, Rust ne peut pas garantir l'exécution de la fonction puisque le trait prendrait possession de la fonction. Or cette closure peut être un pointeur sur fonction, ce qui retirerait la propriété de cette dernière de sa structure.

Ce qui est super c'est que la documentation possède un tableau comparant la complexité des différentes structures en fonction des cas d'utilisation.

Différences entre les enums Option et Result en Rust.

Il n'y a pas à dire, à chaque fois que je code et où le langage m'oblige à utiliser des Optional, je me dis que c'est un langage pourri. Et ceci inclus Rust malgré tout le bien que je pense de lui 😤 !

La meilleure façon de gérer les cas de nullité se trouve dans Kotlin 🥰, TypeScript et Groovy. Le type Optional est une technique archaïque et verbeuse quand on vient du null-check de Kotlin.

Mais bon j'ai déjà expliqué par le passé en quoi le paradigme fonctionnel pure était un cancer métastasé 🤮. Et entre C++ et Rust pour de la programmation système il n'y a plus vraiment de discussion à cette heure, donc faisons-nous violence avec les Optional.

Mon rêve serait un langage natif reprenant la syntaxe de Kotlin (sauf tout ce qui touche aux getter/setter) avec le borrow checker de Rust et qui produise des binaires natifs. Je pense que je peux rêver encore longtemps 🥲

L'idée est de tirer 100% des optimisations possibles sur une architecture donnée pour ne cibler qu'elle mais ne plus être portable en contrepartie.

Il suffit de déclarer la variable d'environnement RUSTFLAGS comme ceci :

# Cibler la plateforme sur laquelle est construit le binaire
RUSTFLAGS="-C target-cpu=native"

# CPU Intel
RUSTFLAGS="-C target-cpu=skylake"

# CPU AMD
RUSTFLAGS="-C target-cpu=znver2"