6 ms·
um, 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
by 38 3y ago
um, 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.
- 38 3y agoI don't see include, which means you're ignoring warnings aren't printing them in the first place. Also testing against a number instead of boolean. Also you have a horrible hack instead of proper flag parsing. And you're also abusing brace elision just to reduce LOC. And again abusing ternary syntax for the same reason.
- deleted 3y ago[deleted]
- mturmon 3y agoIf you start with code golf, as you did, then this is where you end up. The only way to win is not to play?
- 38 3y agomine is just normal idiomatic Go code. thats not true of the C code.
- inferiorhuman 3y agoIt might be ugly, but that is idiomatic C code. C didn't even have boolean types until C99, and even then it's an "extension" of an integer type. You could argue about the loop itself, after all K&R specified "for(;;)", but the other commonly used (ergo idiomatic) infinite loops use precisely the same number of lines. "while(1)" is a perfectly idiomatic manner to create an infinite loop. Likewise a void return type for main was entirely legal until C99. The BSD yes(1) I've laying around only prints the first argument, so flag parsing? What flag parsing? Yes in nine lines of C inclusive of preprocessor macro invocations and white space. #include <stdio.h> int main(int argc, char **argv) { const char *phrase = argc > 1 ? argv[1] : "y"; while (1) { printf("%s\n", phrase); } return 0; }
- 38 3y agoI don't see proper flag parsing, I see an argv hack.
- staplung 3y agoOn my mac the go version of yes creates a binary that's 30x larger than the yes binary I have on a linux machine. 2MB vs ~65KB.
- svnpenn 3y agoon mine it is 1,354 KB. I prefer the 10x LOC savings over a megabyte of hard drive, but you do you.
- BenjiWiebe 3y agoBut if everything was written in Go it might be 1 megabyte * the number of users of coreutils. Might be worth using a few more lines of code to save a little bit of space on a lot of machines.
- commonlisp94 3y agoIt's not about hard drive space, it's about start up time. The 10x LOC (despite being a huge exaggeration) is also the fixed cost, not the marginal cost. You're only forging main loop and includes, not any fundamental complexity. This is also a funny argument coming from a Go programmer considering that Go trades off conciseness and expressivity for simplicity. Show me some of your favorite Go and I'm sure we can replace it with some concise C++.
- 38 3y ago> C++ I just physically shuddered
- commonlisp94 3y agoI bet you did.
- smashed 3y agoThis. In fact, most embedded Linux thingy will be running the busybox version of core utilities instead of gnu coreutils for binary size reasons. I other words, even gnu coreutils is too big.
- 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