C vs GO

> Looking at other systems such as Haiku shows that porting Go is encouraged, the only issues have to deal with assumptions in the build (in this case, I think /bin/env/bash is included everywhere, there's no global variable to change this definition from different OS types).

I think this is not longer a problem with the new build system that is part of Go 1.

Also AFAIK at least the Plan 9 port is almost complete, and is certainly functional.

Goroutines are great, but I'm not convinced they are the greatest advantage over C.

Go cleans up and fixes pretty much every issue C had, and improves it in many non-obvious areas, from the syntax to the type system.

And when porting an existing project I'm not surprised if goroutines would come up that often given that they probably don't have any equivalent in the original design.

I mean, the only other living inventor of C is working on Go...

I like Go but it's not a replacement or even just competition for C. Garbage collection alone ensures that.

C is for low-level code, where you usually want deterministic, real-time behavior. Go cannot deliver that because of its GC.

You can certainly write web server software in Go (what Go was designed for), but could you write an "AAA" video game in it? Or a mission critical embedded system with real-time requirements?

Also, the author's portrayal of C is misleading. If you have 'naked' malloc() calls all over your code you are doing something wrong. Much C code never calls malloc() or follows the "no allocation after initialization" principle.

If you write C like Python you will run into problems. In C you do not wildly allocate objects on the heap all across the program. E.g. in my current program almost everything comes out of memory pools. E.g.

Object* object = ObjectNew();

..and if I forgot to release it I would know quickly because any "memory leak" would cause the (pre-allocated, fixed size) memory pool to run out of free slots. In C you should manage memory in a systematic fashion.

I think the C standard library should be seen as the very foundation of a program, something you use to build the abstractions which solve the problem, not something you use directly to solve the problem. People often warn about the dangers of strcpy() (an the author uses it). I never use it except at the lowest levels. At the high level robust C code looks more like this:

ObjectSetName(object, newName);

than this

strcpy(object->name, newName);

..the difference is that ObjectSetName() can internally guard against overflow and that the concrete details of the object data structure remain hidden and thus later code changes are easier. It is a very common C idiom to use incomplete types and such functions to achieve a very high level of encapsulation.

Your C code looks very unidiomatic to me, but I guess that is relatively a matter of taste (still I don't understand why would somebody use C if they don't like to write code in the 'classic' C style as seen in the original Unix and Plan 9 source).

That aside, in Go you can also do fixed allocations and manage your own memory pools to avoid the GC.

And I would also question how many C programs require real-time behaviour (even the definition of 'real-time' has issues, most things people call 'real-time' aren't).