Live data from Hacker News

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

github.com

61–70 of 170 posts

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

#61

Earlier quoted context omitted.

If you are looking for a non-joke implementation[0]. Excluding the test code at the bottom, the Rust version is a bit less than 120 lines. [0] https://github.com/uutils/coreutils/blob/main/src/uu/yes/src...

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

That reddit thread has some amazing benchmarks.

The GNU-yes

  $ yes | pv > /dev/null
  ... [10.2GiB/s] ...
The way I (not a C programmer) would have written it

  void main() {
      while(write(1, "y\n", 2)); // 1 is stdout
  }

  $ gcc yes.c -o yes
  $ ./yes | pv > /dev/null
  ... [6.21 MiB/s] ...

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

#62

Nicely done but not enterprise ready if you ask me (which you did not but let's assume you did). Where is the 'y' factory factory factory method? Do you really think I can present this code as being ready for company-wide deployment (me and my virtual friends) without the solid foundation of all 26 design patterns clearly being implemented? Where is the code diversity statement, where is the code code of code coding…

This is rust, not Java.

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

#63

Earlier quoted context omitted.

> It uses an unsafe code block. it's okay, it's Rust unsafe

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.

No, no. Rust's unsafe is fine. After all unsafe is not a problem because it is directly obvious just by looking at the source of your 200 dependencies. If you still have doubts you can make sure everything it is ok simply by writing "SAFETY" next to it to point out that it is safe (btw: not having this is a serious omission in the yes-rs project). And anyway, the compiler still does basically almost all checks! This rest is entirely obvious in Rust. For example, there can never be a subtle exception-related issue that make this difficult to analyze because in Rust it is called panic. And if there is still should be a mistake, then this does not count because it was not the fault of Rust but yours. (This is totally different to C where even the most-expert programmer can never know when he is going to free memory or doing pointer arithmetic. This could literally occur completely surprisingly in every line of code!)

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

#64

Earlier quoted context omitted.

I recommend reading through this section of the The Rust Programming Language book to learn more about the existence of Unsafe Rust which is a part of Rust and not a different language like C or C++. https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html

My friend on the off chance that you truly don’t see it: they’re teasing you

[deleted]

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

#65

Nicely done but not enterprise ready if you ask me (which you did not but let's assume you did). Where is the 'y' factory factory factory method? Do you really think I can present this code as being ready for company-wide deployment (me and my virtual friends) without the solid foundation of all 26 design patterns clearly being implemented? Where is the code diversity statement, where is the code code of code coding…

Exactly this. For a genuinely web-scale implementation, these days in an enterprise context you really need to be thinking about a “yes” microservice that can be run in an autoscaling kubernetes framework. Doesn’t need to be fancy just a couple of helm charts and a security sidecar with ingress and egress filtering, a rate limiting API gateway and a logging component of course. And metrics. Put it behind an application firewall and a CDN and you should be all the way done in a sprint or two if your team is agile.

I mean, just think about what would happen if clients became blocked on your yes service because you couldn’t scale fast enough?

If you don’t think your devops team is up to the challenge of maintaining 24/7 yes coverage (and there’s no shame in that), there are no shortage of “yes-as-a-service” providers you can make use of, provided they can implement your sso auth flow and have all the requisite soc2/iso27001 certs. Like most vendors you’ll likely need to help them through GDPR/CCPA compliance though.

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

#66
post #4

Earlier quoted context omitted.

yes-rs is a joke, not a serious project.

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

You're right. We need to up vote these repos and write blog posts about them.

In fact LLMs are perfect for this..!

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

#68

Earlier quoted context omitted.

If you are looking for a non-joke implementation[0]. Excluding the test code at the bottom, the Rust version is a bit less than 120 lines. [0] https://github.com/uutils/coreutils/blob/main/src/uu/yes/src...

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

In this case OpenBSD version does a much better job imo (although I don't agree with the lack of braces). The performance of such a tool does not matter at all, and a larger implementation is not only unnecessary, but it can actually introduce bugs in otherwise completely straightforward code

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

#69

Earlier quoted context omitted.

I recommend reading through this section of the The Rust Programming Language book to learn more about the existence of Unsafe Rust which is a part of Rust and not a different language like C or C++. https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html

My friend on the off chance that you truly don’t see it: they’re teasing you

Rust community is not a place for such behaviour, they are both pretty serious in their opinions

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

#70
post #6

Earlier quoted context omitted.

Until I actually went to read the code, I thought this was just a kinda lame overplayed joke, but the number of lines they listed made me really curious: how did they manage to beef up the SLOC that much? After reading a bit of the source code, I take it back. That's definitely venturing into the territory of art.

// 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!

It does have blockchain though, you can search for a substring in the code
Post reply on HN