[kosherhurricane]

I work on a code base that is a mixture of Go and C.

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.

[dist1ll]

> C is fast because it's close to how CPU and memory actually work.

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....

[kosherhurricane]

C is an abstraction, and most (all?) cpu architectures pretends to be c machines.

I don't know of any other way of manipulating the cpu as closely as C and assembly. Do you?

[AtNightWeCode]

I do prefer Go over C in most cases and it's not like there are no pitfalls in C. It is just disappointing when a lang doesn't improve over time and have the same stupid problems year after year.

[YesThatTom2]

Here’s an article that refutes your claims. https://queue.acm.org/detail.cfm?id=3212479

[kosherhurricane]

I know about this article. Thank 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?