Perhaps most people use 64 bit on their servers nowadays.

Judging by the rate of releases of minor versions of Go, I bet it will be fixed in about two months from now. They are certanly aware of the issue.

The issue is actually impossible to fix without overhauling the entire language. It's impossible to garbage collect unboxed objects without being conservative.

Exactly. But conservative GC sounds like a dumb idea in the first place. Im not the expert these people designing these languages are, but i can not understand how memory leaks can ever be acceptable just because the probability of it seriously affecting you, is low (when on x64). Doesnt that just imply you can not use these types of languages in any mission critical context.

I must be wrong though: it seems Google is using it for parts of their infrastructure, and im assuming those are long running procceses. But what if the worst case scenario does happen? Are there workarounds? Monitor memory usage, and just restart? Can we force the runtime to free a certain resource?

What am i missing? How does this not completely destroy anu utility of these languages? Why do people put conservative gc in languages outside of the esoteric or academic context?

> Doesnt that just imply you can not use these types of languages in any mission critical context.

No more so than with C++. There is a relatively high probability of you having left a memory leak in an average C++ server.

> Monitor memory usage, and just restart?

That would work, and is probably a good idea for all servers anyways. I've seen apache take upwards of 60 gigs due to some misconfiguration, so monitoring memory utilization of your programs and alerting or automatically restarting is a good idea.

> What am i missing? How does this not completely destroy anu utility of these languages? Why do people put conservative gc in languages outside of the esoteric or academic context?

There isn't really a good reason as far as I can tell. The only advantages are that its much simpler to implement, particularly when you have C interop. You can annotate Go objects with types to do precise collection, but as soon as you pass them to C, a lot of guarantees the Go typesystem makes go out the window. Other than that, can't think of anything.

It is my understanding the chance of complications is lower on a 64 bit system. But it is very likely, that well crafted requests can make any server application written in Go, trigger this complication, and essentially result in a DOS attack.

I think it would be mindblowingly difficult to cause this DOS. If you think it possible, you can setup a demo on appengine. You even get to upload the source code, so you have that advantage, that you wouldn't ordinarily have.

Gist of the task at hand: you'd have to arrange for data passed into your target application to point to structures in memory, causing them to be pinned. Ideally, these structures should be big, to maximize impact of the attack. Further, you'd have to ensure that the data you passed in isn't garbage collected, as this would allow the target structures to be collected.