11 ms·
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 det
by copx 14y ago
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.
- luriel 14y agoYour 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).
- nux6 14y agoE.g. any app with [record] button need to meet 'mostly' predicted system latency, that's 'soft-real-time'. Any professional app with [play] and [record] button needs a minimal warranted latency, that's 'hard-real-time'. Go is unsuitable for both.
- batista 14y agoI fail to see how Go is "unsuitable" for even the pro use case. Go could do a recording type application with minimal guaranteed latency just fine, and the GC won't stop it doing so.
- scott_s 14y agoWhile I agree that Go is suitable for his examples, it's not suitable for hard real-time. As far as I know, its GC does not have bounded latencies. There are GCs that do have bounded latencies (see the Metronome project for Java's GC: http://researcher.ibm.com/researcher/view_project.php?id=174 http://researcher.ibm.com/researcher/view_project.php?id=174) which then allow them to be used for hard real-time systems.
- luriel 14y agoThis is not really an issue with the language but with the implemetnation and most languages/libraries/OS-es are not suited for "hard real-time" either. How many people are writing "hard real-time" code? I suspect not many, and yes, for them probably Go is not the right tool at the moment, but also in great part because nobody has needed/wanted to use Go in such environments yet.
- scott_s 14y agoRequiring garbage collection is a language issue, not just an implementation issue. (Note that I do not think GC is a bad thing, but it matters a great deal in this context.) Making GC work in hard real-time system is a Hard Problem. I think you greatly underestimate how difficult it is, given your final sentence. Read the Metronome project I linked to. You are correct that not many people write hard real-time code; it's generally found in such things as software controlling planes, power grids or power plants.
- jamesgeck0 14y ago> but could you write an "AAA" video game in it? Perhaps not, but an extremely large percentage of commercial indie games are written in managed languages.
- regularfry 14y agoMy chief worry over Go at the moment isn't that is has GC (for the most part), but that the GC it does have is relatively dumb.
- luriel 14y agoThe GC in Go 1 is a bit smarter than it used to be, and it is going to be even smarter in Go 1.1, this things take time, and the current GC works quite well for most people. Also Go gives you control over memory layout, which allows you to avoid some GC issues that are much more difficult in languages like Java.
- stcredzero 14y agoYou can avoid those things in Java as well, by adjusting settings. Adjusting eden and generation sizes with generational GC is a bit of an art for all but the simple cases.
- eswangren 14y agoYes, but they tend to be relatively trivial (in terms of performance) in comparison to AAA titles.
- heretohelp 14y agoNo really; I know a number of very talented systems programmers and grew up with C myself. Your C is not idiomatic even if you're right about avoiding naked mallocs and Go not being appropriate for systems programming.