3 ms·
I'm not sure about Go specifically (as I have yet to write a non-trivial project in Go) but D at least allows you to do manual memory management, if you so desi
by andolanra 16y ago
I'm not sure about Go specifically (as I have yet to write a non-trivial project in Go) but D at least allows you to do manual memory management, if you so desire--down to using std.c.stdlib.malloc, which is exactly what it sounds like--although garbage collection is on by default. I usually tell people it's "...mostly garbage-collected," which tries to convey the flavor of a choice between fine-grained systems-level control and instantiate-and-forget application-level control.
To be fair to the author, I'm going to assume that the most esoteric (read: non-C-like) language he knows is probably Python, because he doesn't compare it to anything besides Python, C, C++, or Java. I also assume he left out Java because by "compiled languages" he meant "compiled to native code without relying on a runtime which is external to the compiled application." He's still missing a whole swath of compiled languages, but there is a point of view from which his comment makes sense, i.e. native-code compilation of C-like systems or applications languages.
("...you will find that many of the truths we cling to depend greatly on our own point of view.")
- dadkins 16y agox = new(foo) ... x = nil There. Manual memory management. What? It's not as if when you free() something that was malloc()'ed, it gets returned to the operating system right away. It just goes back on the free list. Garbage collection amortizes that.
- andolanra 16y agoWell, by the same token, you can take Python's x = Foo() ... del x as manual memory management, after a fashion (which it is). The kind of manual memory management I'm concerned about is less about having precise control over when memory passes in and out of my program's control, and more about controlling fragmentation and time spent searching for unused memory. For example, would slab allocation--an extremely useful technique for operating systems, databases, &c--be possible in Go? Addendum: I'm not trying to denigrate Go, and I don't mean to suggest having or not having fine control over memory makes or breaks a programming language, because it's a valuable tool in certain instances and a hindrance in others. I honestly don't know whether or not it's possible in Go; I suspect it is, to some extent, although it would no doubt be discouraged by the design of the language.
- jpr 16y ago"What", exactly. If Go really deleted the object pointed to by x when you set x to nil, it would be seriously flawed (though I wouldn't actually be surprised if this was the case, it certainly is flawed in many other ways).