Nap vicce - yes rustban implementálva

Annó volt egy vicc, hogy minden új program nyelv az azt kitaláló programozók megélhetését hivatott biztosítani. Minél elcseszettebb a nyelv, és minél komplikáltabb, annál biztosabbak a nyugdíjas évek. Különösen, ha a nyelv megkerülhetetlenné válik.

Aztán jött a Rust, és hirtelen felvillantotta az összes létező figyelmeztető lámpát.

Azóta mindent is rozsdásítanak, és már a linuxba is próbálják betenni a lábukat. 

Legutóbbi áldozatuk a kicsit öreg, kicsit semmire sem jó, yes program. Mégis mit lehet javítani egy parametrikus végtelen cikluson? Rengeteget! Például fel lehet tupírozni az 50 soros kódot legalább 1302-re! Komolyan? Komolyan!

De legalább blazing fast és memory safe!!!!!!44444!!!!

Innen lehet letölteni:

https://github.com/jedisct1/yes-rs

(A mai napi blogbejegyzést a Programmer Literacy Survey támogatta.)

( bennyh | 2025. 05. 27., k – 08:04 )

Már bocs, de nem része a Core utils-nak? Mert akkor így-is-úgy is rozsdásítva lenne, tök feleslegesen dolgozott. Az meg hogy 50 sorból 1302 lett, nem feltétlen a nyelv hibája. 

( Fisher v | 2025. 05. 27., k – 08:11 )

Nekem, laikusnak, inkább tűnik paródiának.

Remélem eltaláltam.

( sabe v | 2025. 05. 27., k – 09:10 )

Ez vicces :)
// TODO: hide the unsafe keyword in a dependency
unsafe impl GlobalAlloc for QuantumEnhancedBlazinglyFastAllocator {

 

bitflags! {
    #[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
    struct CrabOptimizationFlags: u128 {
        const ZERO_COST_ABSTRACTIONS = 0b00000001;
        const FEARLESS_CONCURRENCY = 0b00000010;
        const MEMORY_SAFETY = 0b00000100;
        const BLAZING_FAST_PERFORMANCE = 0b00001000;
        const CRAB_GRADE = 0b00010000;
        const WEBASSEMBLY_READY = 0b00100000;
        const QUANTUM_RESISTANT = 0b01000000;
        const AI_POWERED = 0b10000000;
        const BLOCKCHAIN_ENABLED = 0b100000000;
        const CLOUD_NATIVE = 0b1000000000;
        const MICROSERVICE_ARCHITECTURE = 0b10000000000;
        const SERVERLESS_COMPUTING = 0b100000000000;
        const EDGE_COMPUTING = 0b1000000000000;
        const MACHINE_LEARNING_OPTIMIZED = 0b10000000000000;
        const IOT_COMPATIBLE = 0b100000000000000;
        const KUBERNETES_NATIVE = 0b1000000000000000;
    }
}

( sabe v | 2025. 05. 27., k – 09:12 )

Szerintem jól szórakozott a készítője
            eprintln!("📦 DEPRECATION NOTICE: This crate will be abandoned in 6 months");
            eprintln!("   as per Rust ecosystem best practices. Start migrating to:");
            eprintln!("   • yes-rs-2 (rewritten with different dependencies)");
            eprintln!("   • yes-rs-ng (Angular-inspired architecture)");
            eprintln!("   • yes-oxide (WebAssembly-first approach)");

( persicsb | 2025. 05. 27., k – 10:30 )

Ez egy paródia, ha nem tűnt volna fel.

( apal v | 2025. 05. 27., k – 10:39 )

Egyelore probalom buildelni... mar ~15 perce szuttyog, valami "Updating crates.io index" meg "resolving deltas" dolgokra hivatkozva. A ~/.cargo konyvtar mar ~1 gigas. 

Task failed successfully:

.../yes-rs-main$ cargo build --release
    Updating crates.io index
  Downloaded futures-sink v0.3.31
  Downloaded metrics-macros v0.7.1
[...]
  Downloaded tokio v1.45.1
  Downloaded 84 crates (7.5 MB) in 1.28s
error: package `tokio v1.45.1` cannot be built because it requires rustc 1.70 or newer, while the currently active rustc version is 1.63.0
Either upgrade to rustc 1.70 or newer, or use
cargo update -p tokio@1.45.1 --precise ver
where `ver` is the latest version of `tokio` supporting rustc 1.63.0
.../yes-rs-main$

Az ketsegtelen hogy otvar regi, stable Debian-t (konyvkukac) hasznalok. 

Hm... lehet hogy meg kene probalnom a coreutils-rs-t is :) Szerk: annak mintha 1.85.0-s rustc kellene, de nem itt bukott el hanem a cargo verzio volt regi... hat, igy jartam. 

( lcsaszar v | 2025. 05. 27., k – 12:59 )

Ha van yes n, akkor miért nincs inkább no ?

Igazából nem nagy kunszt az argv[0]-t nézni, és ha az "no" akkor megfuttatni a kódot automatikusan "n" paraméterrel. Legalábbis C-ben lehet ilyet, nem vagyok elég rozsdás még ahhoz, hogy a másikat is tudjam.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( Dwokfur v | 2025. 05. 27., k – 16:15 )

Hiánypótló projekt! Hiányolom még, hogy néhány fejlesztőt kirakjanak a világnézete miatt, illetve a dokumentációból egy hitvallást, hogy ne használja senki, akinek nem egyezik a politikai nézete / nem Antifa tag.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( YleGreg | 2025. 05. 29., cs – 22:46 )

A yes az egy abszolute határozott állítás, vagyis maszkulin vonásokat hordoz. Ezért kéne egy she-yes program, aminek a kimenete néha yes, néha no, néha valami tavaly előtti random vita találomra kiragadott eleme, néha pedig valami olyan, amire már tényleg nem tudsz semmi értelmeset válaszolni. Mert a gendersemlegesség fontos. :-)