-1
-1
It's IO, CPU and Memory hungry, and it's distributed.
C is fast because it's close to how CPU and memory actually work. Go gives you 95+% of that plus easy to learn, easy to use language. A new person could start contributing useful features and bug fixes immediately. A senior person could get C-level performance.
More and more of our code is moved from C to Go, with very little performance penalty, but with a lot more safety and ease of use.
Our customers benefit, and our company makes more money.
In the end, that's what software is about.
Out-of-order execution, cache hierarchies, branch prediction, virtual memory, pipelining, vector instructions, ILP, NUMA are all pretty transparent to the C spec.
Trying to accommodat hardware quirks with C feels like blackbox engineering. It's certainly better than with managed languages but still....
I don't know of any other way of manipulating the cpu as closely as C and assembly. Do you?
I said C is "close to" how a computer works. C is an abstraction, and most (all?) cpu architectures pretends to be c machines. There was a talk (Kelly?) where even assembly is nowhere close to what a cpu actually does.
I don't know of any other way of manipulating the cpu as closely as C and assembly. Do you?