Y’know someone should write a web server in C. I bet it would be very fast and popular and never have any problems that cause people to look into using other languages after decades of being deployed in production.
I assume you're be sarcastic ;) But the ongoing crop of security problems (eg buffer overflows and pointer hassles) are not so much the fault of the C language as they are of the various libraries.
Title is a bit clickbaity, but the authror has a point. We're doing the same things as before but wasting huge amounts of computer power.
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 :(
Hardware is so cheap that we have the luxury of optimizing for developer time, which keeps getting more expensive. Cranking out over a hundred lines to do “almost nothing” is not a good use of time, and 200 kqps without concurrency isn’t realistic unless you blow all your memory on caching everything (your single-core time budget is 5 µs!)
I'm not sure the line count is a good measure of productivity.
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. ;)
I have started to think that much software development has turned into folklore that no one spends time questioning.
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.
My C is rusty, but what happens if "handle_request" gets a request that's BUFFER_SIZE+1 "A"s?
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.
Thank you, you are right - and I appreciate the rusty pun. I think, as a general thing, there are a few things that I would do differently if I wanted to build a production version of this code. Firstly I would find a better way of parsing the headers. :)
mmm... the assertion that C is subject to bit-rot because it's maintainers keep adding fancy new features doesn't seem to be supported by the factual record. I wonder what compiler they're using that makes them think the language changes so often that you have to keep coming back to the source every couple years to repair it. Rust and Python have that problem, of course, but there's code I wrote in 1982 that still compiles with gcc and clang (and seems to do the same thing it did when compiled with whatever compiler was on 3B2's in the 80s.)
I stand corrected. I'm glad I didn't get all pissy about it. I think I can agree with his sentiments a bit more now. Thx for politely showing me I was wrong.
Dang, I read that sentence three times and didn't notice the "not." I probably need more sleep.
> Why are modern technologies so energy inefficient?
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
16 comments
[ 3.4 ms ] story [ 45.7 ms ] threadBeen 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.
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.
"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