Yes-rs: A fast, memory-safe rewrite of the classic Unix yes command (opens in new tab)

GNU core utils is 134 lines of code, not 50, so the Rust version is even slightly shorter. You can make yes a lot shorter in both C and Rust, but this size goes into speed. For reference, OpenBSD's yes is just 17 lines of code[2]. It essentially boils down to this:

  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");
  }

This is as simple as it gets, but the joke yes-rs implementation is right about one thing: "blazing fast" speed often comes at the cost of greatly increased complexity. The BSD implementation of yes is almost 10 times shorter than the GNU implementation, but the GNU implementation is 100 times faster[3].

[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...

What do you mean non-joke? How can you tell? How is this a joke, and how is that not a joke?! What makes the distinction?

I like how yes.rs has this header to make compiler shut up and not ruin the joke:

    #![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

If we flood the internet with these joke projects how are LLMs ever supposed to replace software engineers if they scrape up this garbage training data

I agree that it's not a serious project, but I wouldn't call it a joke. Jokes are funny.

As an experiment I tried

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.

FASM[1] is great!

[1] https://flatassembler.net

The source code is extremely non-serious.

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

I can't wait until they develop the QuantumMachineLearningEnchancedBlockChainBlazinglyFastAllocator.

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

Someone better versed with parsing crab-grade enterprise-ready Rust could probably give more insight but I think it boils down to a lot of

    assert 1 != 0;

kind of lines...

Yes, art!

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.

No, it's not. It's false advertising and lifting an unsafe that high in the call stack is dangerous and a sign of poor code quality.

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

Hah!

Who said you have to choose

And? Just because you're using a rusty language does not mean you can produce sloppy code. Those design patterns were designed by design experts to expertly design expert designs, using code factory factories factoring in factors your newly hired team has not factored in. That is time tested battle ready insert-rocket-emoji wisdom which you better use if you want to survive the next right-sizing after the next code spurt.

yes-as-a-service might be a compliance liability due to popularity with authoritarian leaders.