Go [LWN.net]

Go

Posted Jul 14, 2013 22:23 UTC (Sun) by juliank (guest, #45896)
In reply to: Go by Cato
Parent article: The next 20 years of Python

But most likely not longer than 15 years, because they almost all have 32-bit time_t values. So, it's not that problematic.

to post comments

Go

Posted Jul 15, 2013 0:19 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (4 responses)

Doesn't x32 fix this?

Go

Posted Jul 15, 2013 11:30 UTC (Mon) by juliank (guest, #45896) [Link] (3 responses)

That's just one architecture, though; and one you could just run a 64-bit environment on easily. I was more talking about ARM (and other architectures like Mips exist as well, but Go is not ported to them AFAICT).

Go

Posted Jul 15, 2013 23:26 UTC (Mon) by lsl (guest, #86508) [Link] (2 responses)

You can compile your code with gccgo to run on MIPS and other GCC targets.

Go

Posted Jul 16, 2013 8:49 UTC (Tue) by juliank (guest, #45896) [Link] (1 responses)

But is gccgo compiled code affected by the same GC issues?

Go

Posted Jul 16, 2013 20:09 UTC (Tue) by lsl (guest, #86508) [Link]

Yes, as the runtime used in gccgo is (mostly) the same. But the issue isn't as bad as people make it sound. I wouldn't worry about it. The GC is constantly improving and even now, with Go 1.1 (in GCC 4.8.1), you shouldn't have any problems outside of some pathological cases

Also note that Go gives you enough control over memory that you can easily work around those cases, should you actually encounter them.