Is All Programming a Scam?
blog.ajour.io
blog.ajour.io
Been my position for quite some time. But you can imagine it doesn't go down well on HN. Here latest language/machine/etc is of great interest, and keeping-up-with-the-xxxs is normally seen as vital :(
Is that true on the note of "optimizing for developer time"? Do people actually have an understanding of the tradeoff they are making? Do the teams building applications in Java actually know what it would take to do them in C, and choose that the tradeoff is too big? Does the Typescript backend developer know what it would take to do the same in C++ and decide against it?
Or are they mainly working out of a preconceived bias that their favorite language is best and that everything else is worse?
For the 5 µs, I recall a currency conversion system(tin-cup) with in-memory currency rates whose only job was to convert incoming requests to USD. Ignoring the fact that this should never have been an independent system. This seems like a perfect use case for working in a highly optimized environment. ;)
Questions like: "Does using Typescript for your backend make you, the programmer, faster/more efficient?" "Do I need a full-blown ORM framework to interact with my database?" "Do I need a runtime with lightweight threads?"
I also have started developing a headache every time someone claims that they are optimizing for developer productivity but cannot articulate the tradeoff they are making.
If you use technologies that cause you to use 20x the hardware, you will need to run complicated DevOps, or whatever we call it, very early.
I have companies with ten concurrent users using Terraform to spin up their microservices in multiple regions on beefy machines. With mental/developer overhead of dealing with the complexity of large distributed systems, YEARS before their company needs the complexity. You are not optimizing for developer productivity; you are just doing random stuff, and claiming that its best practice.
"As a side note, the C program will most likely not endure bit-rot due to new fancy features being rolled out in the next version of the language."
Dang, I read that sentence three times and didn't notice the "not." I probably need more sleep.
First off, framing this as "inefficiency" seems inappropriate because we are not doing comparison of identical things.
If the output of each language was identical and one spent less energy than the other to produce it, we could frame it this way successfully.
Next, this question isn't unlike asking: "why is my bicycle more efficient than my car?"
Well, once again, it's not a 1-1 comparison. The car is doing more work, able to carry more weight further. It is using more energy but it is quite likely more efficient than your bicycle. Plus, it allows you to accomplish things your bike never could.
Similarly C is doing the least work (hence seemingly more efficient) while JS is doing the most. Sure not all that work JS is doing is "useful" work but Rust version for example is likely more secure, so it is still "better" and possibly more efficient than the C version. All the work that C is not doing, like checking for buffer overflows, makes it look like it is more efficient but that's not the kind of efficiency we really want.
There is real inefficiency in using existing libraries (in any language) rather than tailoring every method to the application at hand. That's an economic trade off as mentioned by others and has nothing to do with energy efficiency
Seems to me like "read" will read exactly BUFFER_SIZE "A"s and no null-terminator, causing the subsequent "strsep" to find the first \n... someplace in memory (after the buffer) and overwrite it with a null-terminator.