4 ms·
here is a Go implementation for fun: package main import "flag" func main() { yes := flag.String("m", "y", "message") flag.
by 38 3y ago
here is a Go implementation for fun:
package main
import "flag"
func main() {
yes := flag.String("m", "y", "message")
flag.Parse()
for {
println(*yes)
}
}
- sltkr 3y agoHere's a Brainfuck implementation: ++++++++++[->++++++++++++>+<<]>+[.>.<] (Unfortunately, Brainfuck doesn't support command line flags.)
- dale_glass 3y agoYeah, GNU yes could be about that simple but it's a good deal more complex to obtain the best performance possible: https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/ https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...
- 38 3y agoum, who cares? most times people are needing to use "yes" as part of a "configure" script or similar. even if GNU yes was 10 times slower, it would NEVER be the bottleneck in any situation. so whats the point?
- the-smug-one 3y agoYou'll have to ask the author that. Now, I'd like to ask the author who cares how you implement 'yes' in Go ;-).
- 38 3y agoyes C lines of code: 112 yes Go lines of code: 9
- placesalt 3y ago16 lines of go, with comments & whitespace
- 38 3y ago134 lines of C, with comments & whitespace
- deleted 3y ago[deleted]
- not2b 3y agoThat isn't an apples-to-apples comparison. A C version could be similarly short, but the GNU yes implementer got carried away with efficiency considerations. If the Go program did the same, it would be longer.
- hunson_abadeer 3y agoIt feels like you're making a bad-faith argument here. You can implement 'yes' in a straightforward way in a couple lines of C, too. main(int argc, char** argv) { while (1) { if (argc > 1) for (int i = 1; i < argc; i++) printf("%s%c", argv[i], (i == argc - 1) ? '\n' : ' '); else puts("y"); } } The point other folks are making is that it's written differently for a reason. Maybe not a reason that's important, but at the very least, let's try to compare apples to apples.
- 3y ago
- dale_glass 3y agoI presume somebody had a need, and scratched the itch. With modern systems we can have 8 channel RAM and 128 PCIe lanes to feed a system stuffed with NVMe drives. The amount of throughput that can be obtained is nuts, and at that point all sorts of weird things can become an unexpected bottleneck. This applies even in consumer systems. Suddenly your game loads far slower on a NVMe than it could because it never occurred to the programmer that instead of the disk, the JPEG decoder can become a bottleneck when you can read compressed data at 7 GB/s.
- eichin 3y agoa decade or so ago, I ran into a problem where "yes" was already too fast, feeding it to apt-get install or something (in a context where we knew what the prompts were doing and if anything unusual happened we'd fail other checks immediately) and it had some clever input buffering going on... that wasn't clever enough and locked up on getting a megabyte of yes'es on the first read() call.
- shrubble 3y agoCheck out 'stdbuf' perhaps?
- singron 3y agoI've heard before that a lot of GNU programs are stretched like this so that they don't resemble anything from proprietary AT&T unix. E.g. all the extra options in basically everything and the ridiculous optimization of things like yes.
- SubjectToChange 3y agoI remember reading that the GNU project was rather keen on avoiding and removing artificial restrictions. In other words, if a feature was useful and reasonable then it should be seriously considered for inclusion. As for the aggressive optimizations that are sometimes seen, I assume it’s just people wanting to improve a tool that’ll be used everywhere, more for fun and/or notoriety than anything else.
- fipar 3y agoI'm not saying this is the reason, but unnecessary (or sometimes dangerous if used in real life) optimizations have been created to speed up QA runs (of course, that only works if what you optimize away is not part of what you're trying to test), e.g., libeatmydata. But for 'yes', I'd agree with you, though I guess the answer to "who cares?" is that whomever wrote it cared. They could have a legit performance reason or may just have done it to show they could.
- rcr 3y agoBecause you can't imagine a case its needed it must not exist? I also remember being a junior dev who thought they had all the answers.
- 38 3y ago[flagged]
- deleted 3y ago[deleted]
- pixelbeat__ 3y agoI optimized yes because: * The fast version is still simple enough * The general functionality being provided is to output arbitrary data repeatedly, and it can be useful to do this as fast as possible
- rcr 3y agoFyi before anyone else decides to read the idiocy that follows in this thread, this is guy is a known troll with a long history of this exact behavior. Same person: https://news.ycombinator.com/item?id=27862463 https://news.ycombinator.com/item?id=27862463 I think this person is just mentally ill unfortunately.
- 38 3y agowhen people resort to doxing, it shows how truly pathetic they are. I pity those people.