Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

141–150 of 170 posts

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

#141

Post by blippage »

alberth wrote: post #2

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

A few days ago I had the very foolish notion of trying to learn assembly for x64 Linux. It came out to 73 lines of code and weighs in at 288 bytes. It doesn't support the --help or --version arguments.

https://gitlab.com/mcturra2000/cerbo/-/blob/master/x64-asm/0...

Some people seem to revel in assembly, but I now know why C exists.

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

#142

Post by johnisgood »

ramon156 wrote: post #139
johnisgood wrote: post #131

Earlier quoted context omitted.

Yeah, and what makes uutils not a joke? It is not immediately obvious to me.

Just checked the readme. If you can't see the obvious tongue-in-cheek way of writing then I don't know what to tell you.

I understand that it is intended as a joke, but jokes often reveal underlying truths. This particular one highlights very real issues, and humor helps us see it through a clearer lens. That said, how can we be certain that uutils is not a joke? Is it purely the intent behind it that distinguishes it?

This joke project has a lot of truths in it that others do dead seriously; something to think about.

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

#143

Post by johnisgood »

blippage wrote: post #141
alberth wrote: post #2

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

A few days ago I had the very foolish notion of trying to learn assembly for x64 Linux. It came out to 73 lines of code and weighs in at 288 bytes. It doesn't support the --help or --version arguments. https://gitlab.com/mcturra2000/cerbo/-/blob/master/x64-asm/0... Some people seem to revel in assembly, but I now know why C exists.

FASM[1] is great!

[1] https://flatassembler.net

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

#144

Post by johnisgood »

layer8 wrote: post #140
williamdclt wrote: post #136

Earlier quoted context omitted.

I was being humorous, but tbh it’s not so clear cut! In 99% of cases, yes of course you’re right, factor this loop. In this specific case? This is trivial code, that will likely _never_ change. If it does change, it’s extremely unlikely that the two loops would accidentally diverge (the dev would likely not miss one branch, tests would catch it, reviewers would catch it). So if you get any upside by keeping the two l…

I agree that it’s borderline pedantic for this simple code, but I also find it an obvious code smell, contradicting the “as simple as it gets”. If you consistently deduplicate code that is supposed to do the same and evolve the same, then any duplicated code sticks out as a statement of “this isn’t the same”, and in the present case it then makes you wonder what is supposed to be different about both cases. In other…

To some, the current way is more readable than yours, though. It is much more explicit, and that often is a good thing.

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

#145

Post by layer8 »

johnisgood wrote: post #144
layer8 wrote: post #140

Earlier quoted context omitted.

I agree that it’s borderline pedantic for this simple code, but I also find it an obvious code smell, contradicting the “as simple as it gets”. If you consistently deduplicate code that is supposed to do the same and evolve the same, then any duplicated code sticks out as a statement of “this isn’t the same”, and in the present case it then makes you wonder what is supposed to be different about both cases. In other…

To some, the current way is more readable than yours, though. It is much more explicit, and that often is a good thing.

I disagree that it’s more explicit. The case distinction and the loop and the puts are exactly the same in both code variants. You can replace the ternary operator by an if if that’s bothering you, that wasn’t the point of the change. The point is to first determine what should be output repeatedly, and then to output it, because the output logic is independent from what is being output (in particular, `yes` and `yes y` should be guaranteed have identical behavior). I don’t really see what’s non-explicit about that. Rather to the contrary, it makes it explicit that the output logic is intended to be independent from what is being output.

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

#146

Post by AlecSchueler »

johnisgood wrote: post #125
mrweasel wrote: post #104

Earlier quoted context omitted.

The OpenBSD version of true is also amazing: https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr... The GNU version of true/false is more interesting. All the logic is in true and false just redefined the EXIT_STATUS and imports all of true.c. https://github.com/coreutils/coreutils/blob/master/src/false...

For reference, here is true.c: https://github.com/coreutils/coreutils/blob/master/src/true.... .

So basically they also introduced the complexity of respecting --help and --version.

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

#147

Post by johnisgood »

layer8 wrote: post #145
johnisgood wrote: post #144

Earlier quoted context omitted.

To some, the current way is more readable than yours, though. It is much more explicit, and that often is a good thing.

I disagree that it’s more explicit. The case distinction and the loop and the puts are exactly the same in both code variants. You can replace the ternary operator by an if if that’s bothering you, that wasn’t the point of the change. The point is to first determine what should be output repeatedly, and then to output it, because the output logic is independent from what is being output (in particular, `yes` and `yes…

How about:

  for (;;) {
    if (argc > 1)
      puts(argv[1]);
    else
      puts("y");
  }
?

You said "it’s about duplicating logic that should inherently be the same", but that is exactly how it is more explicit, by having this duplication. I assume your problem is with the two "puts()"?

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

#148

Post by layer8 »

johnisgood wrote: post #147
layer8 wrote: post #145

Earlier quoted context omitted.

I disagree that it’s more explicit. The case distinction and the loop and the puts are exactly the same in both code variants. You can replace the ternary operator by an if if that’s bothering you, that wasn’t the point of the change. The point is to first determine what should be output repeatedly, and then to output it, because the output logic is independent from what is being output (in particular, `yes` and `yes…

How about: for (;;) { if (argc > 1) puts(argv[1]); else puts("y"); } ? You said "it’s about duplicating logic that should inherently be the same", but that is exactly how it is more explicit, by having this duplication. I assume your problem is with the two "puts()"?

Your proposal is a bit better than the original, although it still duplicates the puts (imagine a variant where you’d want to handle I/O errors), and some will be bothered by the fact that the same unchanging condition is being retested in each loop iteration (the compiler may even warn about it).

But still, I don’t see why you wouldn’t first name what you want to output before starting the outputting. If anything, I’d place the whole output loop in a separate function and have two calls to that function. Nevertheless, it’s even better to express in code the fact that the program doesn’t want to make a distinction between a literal “y” and an argument “y”, by consolidating them into the same variable.

Another way to do this would be to have a static default argument array containing the “y”, and for example having:

    if (argc
This would make explicit the fact thst the argument-less invocation is merely a shortcut for an invocation with an argument and doesn’t otherwise provide any new or different behavior.

Though I think the separate variable (what) is clearly preferable.

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

#149

Post by johnisgood »

layer8 wrote: post #148
johnisgood wrote: post #147

Earlier quoted context omitted.

How about: for (;;) { if (argc > 1) puts(argv[1]); else puts("y"); } ? You said "it’s about duplicating logic that should inherently be the same", but that is exactly how it is more explicit, by having this duplication. I assume your problem is with the two "puts()"?

Your proposal is a bit better than the original, although it still duplicates the puts (imagine a variant where you’d want to handle I/O errors), and some will be bothered by the fact that the same unchanging condition is being retested in each loop iteration (the compiler may even warn about it). But still, I don’t see why you wouldn’t first name what you want to output before starting the outputting. If anything, I…

I have made the decision to use your "what" method many times before, but in this particular case I do not see the reason to do that, and perhaps this is what I have an issue with. There are many cases in which I would definitely use "what".

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

#150

Post by adastra22 »

johnisgood wrote: post #120
adastra22 wrote: post #31

It is abundantly clear here who reads the source code before commenting.

...when you can't make the distinction between a joke and a serious Rust project. Is it not a joke just because the author intended it to be serious?

The source code is extremely non-serious.
Post reply on HN