Hacker News Reader

Comment by MartinMond | Hacker News Reader

Doesn't Go have a GC? How can you then "picture what the C equivalent would look like"?

Yes there are GCs for C, but is anyone successfully doing "systems programming" (whatever that may be) in C with GCs?

> Yes there are GCs for C, but is anyone successfully doing "systems programming" (whatever that may be) in C with GCs?

Actually, yes. But it's hackish (relies on some pretty complex macros) and requires you to adapt certain conventions. Still, it's doable and a whole lot safer than managing your memory directly in terms of leaks and re-use after free. The cost to me really is that macro magic, that should not be required but it's the only thing I could think of to make this work. To give you an idea of just how ugly this is I re-defined 'return'. Any C hacker will be able to deduce the rest from that one hint ;)

On another note, I felt - and feel - that this was not the proper solution but the various policy choices made this pretty much the only way in which it could be done. And it works.

You rolled your own? Why not use the Boehm conservative collector?

In three letters: NIH. Management decision was that all IP had to be 100% owned by the company and had to be in 'C', in spite of an enormous amount of friction between C and the project as well as a bunch of work by others that could have been leveraged if we had decided to use code from other contributors. I got called in long after these decisions were made and it was very clear they weren't going to budge on those. There is a lot more to this story but I'm not at liberty to tell. Let's just say I learned a lot.

So you had to write your own compiler, operating system, and runtime libraries too?

-- I know, you didn't think it made any sense either. I'm just pointing out that a line has to be drawn somewhere; where it gets drawn is actually arbitrary.

Yeah, I've had to deal with ridiculous mandates from on high too, though none anywhere near that onerous. In my previous job, we were writing a compiler. It was mandated to be in C++ -- the first mistake -- and we had to use smart pointers instead of GC -- also a mistake. But the completely idiotic thing was that we were not allowed to declare any exception classes. The VP of Engineering -- a very smart and experienced but very arrogant guy -- had seen exception hierarchies get out of control before and decided the solution was to ban them.

But that's on a pretty small scale compared to what you're talking about.

> So you had to write your own compiler, operating system, and runtime libraries too?

I tried that line and it did not work.

Huh. I wonder how they defined what was acceptable and what wasn't.

Oh well, I'll be fascinated to read the book if you ever write it.

Reminds me of my last^2 job: we were using Scala and the "technical architect" made two decisions that were mildly wrong in isolation but interacted rather badly: we'd make heavy use of monads for core functionality, and we wouldn't use scalaz. So I spent a while reimplementing parts of scalaz, and learned quite a lot (though I doubt I was adding much business value while doing so).

So, the implementation was "conservative", but on a very different level.

Sorry, could not resist.

No, no need to apologize. It's one of the strangest assignments I've ever had and there were a few twists to the whole story that would make for a good book.

That's true. It's not just GC actually. Slices and goroutines don't have a direct analogues in C either. But it is fairly easy to reason about the runtime complexity of these conveniences.

But like I said, if I didn't care about GC or concurrency, I'd be writing C.

Isn't the C equivalent of a slice just a struct containing a *T, a length and a capacity?

And some methods for manipulating it (slicing it), and reference counting. And macro's for automatically ref'ing/unref'ing.

Reference counting? I didn't know reference counting was used with slices, I thought they just used the GC.

Yes, but since C is not a GC-language, I thought I'd add that to reach more equivalence :).

I don't agree with the GP, but if Go were very similar to C and the only big difference would be that C has no GC it would pretty easy to picture what the C equivalent of Go code would be. Exactly the same but with calls to `free()` at the end of some functions. (or preempted between instructions at unpredictable places)

Don't make GC's a bigger deal then they are. They are a tool to remove the need to call `free()` at the right time, with the downside that you don't get to control what the GC thinks is a right time instead.

There's also the overhead of the mark phase, which has to work out dynamically what could be worked out statically in a system with manual memory management. That's where much of the overhead of GC comes from.

I'll add to that that the overhead is not proportional to the amount of garbage your application generates, it's proportional to the amount of data blocks your application has allocated. Garbage collection is also often performed by suspending the application (stop the world) at unpredictable moments and with an unpredictable duration. Garbage collection can thus be a serious problem for some type of applications. This is why the GC should be optional.

> They are a tool to remove the need to call `free()` at the right time, with the downside that you don't get to control what the GC thinks is a right time instead.

That's not actually true. They also allow you to do things that you otherwise couldn't. Try implementing persistent [1] maps or sets without a GC.

[1] http://en.wikipedia.org/wiki/Persistent_data_structure

That's still just a problem of deciding when to call free.

Sort of. But you can't statically decide it. In fact, really the only way to do it is with a GC (or ref. counting, etc.). You can't know until runtime when a node will need to be freed.

And my point still stands. The GC allows you to do things you otherwise couldn't.

Reply on news.ycombinator.com