> I do love how simple and straight forward C is. Calling it hard to debug or write code correctly for is wholly based on the person making such statements.
The statements were that Go is easier to write and debug than C, not that C is hard. Considering that Go is memory safe and a significantly simpler language, it's hard to argue otherwise. As for the person making those statements, you should take a look at Russ Cox's resume.
> Stakeholders, external components, and team factor in.
Indeed they do. In this case, the stakeholders use Go, the external components are written in Go, and the team is the Go team. Go seems like a good fit.
The context of the link and the intended audience (go contributors) are not obvious within the context of a link posted to HN. Sure, you can read through it and look around, but most will read the initial document with their own mindset and experience, so a lack of context is problematic.
I can see how lack of context is problematic for people who simply must share their opinions without delay.
But even without the context, your comments are in response to a misreading of a very small part of the overall document. Hardly seems worth your time.
I am alarmed by anyone who believes C code is easier to build and debug than a modern memory-safe language. C does indeed make it pleasant to build programs that are fast and seem resilient. But the best secure C programmers in the world still routinely manage to get things wrong. qmail, for instance, had an LP64 overflow.
I evaluate the task and the language options. If I needed to prototype out a web service where the server was up to my control, I'd likely shy away from C/C++. In cases where I was writing a module, it would depend on the architecture/framework. Anything low-level or system related, C is my goto well above C++.
Stakeholders, external components, and team factor in.
I do love how simple and straight forward C is. Calling it hard to debug or write code correctly for is wholly based on the person making such statements.