|
|
Log in / Subscribe / Register

Go

Go

Posted Jul 12, 2013 18:56 UTC (Fri) by yodermk (subscriber, #3803)
In reply to: The next 20 years of Python by b7j0c
Parent article: The next 20 years of Python

Yeah. When I was introduced to Go a month or so ago, I pretty much lost interest in Python for server programming almost overnight. Go is almost as easy to write as Python, has static types, and is MUCH more performant.

As for the 32-bit issue, who cares? Is anyone in their right mind still using 32-bit servers? (Ok, I'm sure someone will provide an example of someone who is, but even then they should be looking at migration to 64 bit sometime in the next few years.)

If we back up from Python and consider our entire community, this is a good thing. We don't (or shouldn't) necessarily want *Python*. We want a good solid language that is a joy to use and performs well. Python has been great, but I think Go rightly deserves to be its successor, in many applications anyway.


to post comments

Go

Posted Jul 13, 2013 6:14 UTC (Sat) by b7j0c (guest, #27559) [Link]

no one cares about the 32-bit (non)issue, but its usually brought up by people who are looking to hang something negative on go.

Go

Posted Jul 13, 2013 20:38 UTC (Sat) by Cato (guest, #7643) [Link] (7 responses)

Embedded systems and virtual server instances may be 32-bit for a while yet - e.g. Amazon micro and small instances have less than 1.7 GB RAM. Same goes for smartphones, connected devices, etc. 32-bit systems may outnumber 64-bit for some time, though on servers and desktops they are going away.

However it looks like the 32-bit GC issue is on the way to being fixed.

Go

Posted Jul 14, 2013 22:23 UTC (Sun) by juliank (guest, #45896) [Link] (5 responses)

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

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.

Go

Posted Jul 18, 2013 9:26 UTC (Thu) by farnz (subscriber, #17727) [Link]

There are two counterpoints, though:

  1. 32-bit starts to hit issues at under 1 GiB, and has to use highmem (with all its associated costs) to handle 1 GiB or more.
  2. While Amazon micro and small instances have less than 2 GiB RAM, both support 64-bit platforms; even on the micro instance, with 617 MiB RAM, you could still use a 64-bit OS if that gave you an advantage.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds