In practice very few people have issues on 32bit systems, and for those that do there are workarounds.
Also, Go works much better on 64bit systems for many other reasons, if nothing else because that is what most of the core team uses. 64bit certainly does not double your memory footprint, and it increases performance dramatically (in part because the extra registers, etc., and in part because the Go 64bit compilers are much better).
And as Andrew mentioned, there is a patch already to fully solve things for the few people stuck on 32bits that have any issues.
Finally, all this is an implementation detail, and has very little to do with the qualities of the language. which is what the article is really about.
> In practice very few people have issues on 32bit systems,
I'm not sure what the proportion of people who experience issues is (whether it's "some", "most", or "very few"), but in my anecdotal experience running several long-lived Go processes on a 32-bit VPS it hasn't been a problem.
I think it just comes down to the allocation patterns in your program. Some programs trigger the pathological behavior and others don't.
Regardless of the numbers of affected programs, I'll be glad when the issue is behind us for good.
Also, Go works much better on 64bit systems for many other reasons, if nothing else because that is what most of the core team uses. 64bit certainly does not double your memory footprint, and it increases performance dramatically (in part because the extra registers, etc., and in part because the Go 64bit compilers are much better).
And as Andrew mentioned, there is a patch already to fully solve things for the few people stuck on 32bits that have any issues.
Finally, all this is an implementation detail, and has very little to do with the qualities of the language. which is what the article is really about.