Yes-rs: A fast, memory-safe rewrite of the classic Unix yes command

    #![allow(unused_imports)] // We need ALL the imports for quantum entanglement
    #![allow(dead_code)] // No code is dead in the quantum realm
    #![allow(unused_variables)] // Variables exist in superposition until measured
    #![allow(unused_mut)] // Mutability is a state of mind
    #![allow(unused_macros)] // Our macros exist in quantum superposition until observed
    #![allow(clippy::needless_lifetimes)] // Our lifetimes are NEVER needless - they're crab-grade
    #![allow(clippy::needless_range_loop)] // Our loops are quantum-enhanced, not needless
    #![allow(clippy::too_many_arguments)] // More arguments = more crab features
    #![allow(clippy::large_enum_variant)] // Our errors are crab-sized
    #![allow(clippy::module_inception)] // We inception all the way down
    #![allow(clippy::cognitive_complexity)] // Complexity is our business model
    #![allow(clippy::type_complexity)] // Type complexity demonstrates Rust mastery
    #![allow(clippy::similar_names)] // Similar names create quantum entanglement
    #![allow(clippy::many_single_char_names)] // Single char names are blazingly fast
    #![allow(clippy::redundant_field_names)] // Redundancy is crab safety
    #![allow(clippy::match_bool)] // We match bools with quantum precision
    #![allow(clippy::single_match)] // Every match is special in our codebase
    #![allow(clippy::option_map_unit_fn)] // Unit functions are zero-cost abstractions
    #![allow(clippy::redundant_closure)] // Our closures capture quantum state
    #![allow(clippy::clone_on_copy)] // Cloning is fearless concurrency
    #![allow(clippy::let_and_return)] // Let and return is crab methodology
    #![allow(clippy::useless_conversion)] // No conversion is useless in quantum computing
    #![allow(clippy::identity_op)] // Identity operations preserve quantum coherence
    #![allow(clippy::unusual_byte_groupings)] // Our byte groupings are quantum-optimized
    #![allow(clippy::cast_possible_truncation)] // Truncation is crab-controlled
    #![allow(clippy::cast_sign_loss)] // Sign loss is acceptable in quantum realm
    #![allow(clippy::cast_precision_loss)] // Precision loss is crab-approved
    #![allow(clippy::missing_safety_doc)] // Safety is obvious in quantum operations
    #![allow(clippy::not_unsafe_ptr_arg_deref)] // Our pointers are quantum-safe
    #![allow(clippy::ptr_arg)] // Pointer arguments are crab-optimized
    #![allow(clippy::redundant_pattern_matching)] // Our pattern matching is quantum-precise

  int main(int argc, char *argv[])
  {
    if (pledge("stdio", NULL) == -1)
      err(1, "pledge");
    if (argc > 1)
      for (;;)
        puts(argv[1]);
    else
      for (;;)
        puts("y");
  }

[1] https://github.com/coreutils/coreutils/blob/master/src/yes.c

[2] https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c

[3] https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...

[1] https://flatassembler.net

yes | pv > /dev/null

and was getting about 5.4GiB/s

On the fasm code, I was getting a meagre 7.3MiB/s. Ouch! The non-assembly version is considerably faster. I wonder if it is because I make a syscall for every write I want to perform, whereas C uses buffering, or something.

    assert 1 != 0;

  // Custom crab-grade allocator with quantum optimization
  #[derive(Debug)]
  struct QuantumEnhancedBlazinglyFastAllocator;

I heard Google is giving them a $1bn seed round!

I've been in a constant struggle with Claude Code over variable names. I've picked up speed by just getting the code working, fixing names later.

The variable names are what first jumped out at me, looking at this code. It spoke to my pain.

The point of advertising no unsafe in the readme is so that people do not have to worry if the author handled unsafe correctly.