Earlier quoted context omitted.
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…
Yes-rs: A fast, memory-safe rewrite of the classic Unix yes command
81–90 of 170 posts
Re: Yes-rs: A fast, memory-safe rewrite of the classic Unix yes command
#82Re: Yes-rs: A fast, memory-safe rewrite of the classic Unix yes command
#83Lines of Code yes (GNU) 50 Yes-rs 1,302 (26x more) The cost benefit analysis on this will be interesting given this is 26X more code to manage, and could also introduce a whole new toolchain to build base.
Re: Yes-rs: A fast, memory-safe rewrite of the classic Unix yes command
#84Earlier quoted context omitted.
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
#85I’m eagerly awaiting version 2.0 with AI
Re: Yes-rs: A fast, memory-safe rewrite of the classic Unix yes command
#86Earlier quoted context omitted.
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
LLMs slurp up a lot of trolling and typical tech sarcasm through its training data. IMO a reason for "hallucinations".
Re: Yes-rs: A fast, memory-safe rewrite of the classic Unix yes command
#87Earlier quoted context omitted.
Actually a joke doesn't necessarily needs to be funny, and depending on the framing not even humor. Gregory Bateson's "A Theory of Play and Fantasy" (in Steps to an Ecology of Mind) (1972): Bateson argues that certain communicative acts signal themselves as "play" or "non-literal." A joke is such an act—structured and marked by "metacommunicative" cues, indicating that it should not be taken at face value. Regardless…
so bad joke then??? good joke must be funny
Re: Yes-rs: A fast, memory-safe rewrite of the classic Unix yes command
#88Re: Yes-rs: A fast, memory-safe rewrite of the classic Unix yes command
#89Earlier quoted context omitted.
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
#90Earlier quoted context omitted.
LLMs slurp up a lot of trolling and typical tech sarcasm through its training data. IMO a reason for "hallucinations".
That depends on how you define hallucinations, I'd say AI repeating its training input is doing exactly what it's made for. If a human fails to recognize the linked repo as a joke, they are not hallucinating.