The next 20 years of Python [LWN.net]

The next 20 years of Python

Posted Jul 12, 2013 8:02 UTC (Fri) by b7j0c (guest, #27559)
Parent article: The next 20 years of Python

enough people know and seem to enjoy using python that it seems unlikely that it will go away in fifteen years, or even that people will wish it to go away.

that said, i think the glory days of the 90s scripting language are over. support for types, and more importantly, type inference, means newer tools can provide more safety and performance. since they tend to rely heavily on native shared objects for library support, the 90s scripting languages will always manifest painful dependencies which make deployment a hassle and make concurrency hard.

compare python to go. with go, i get types, type inference, concurrency, and i deploy with scp to any target with the same architecture.

to post comments

The next 20 years of Python

Posted Jul 12, 2013 10:34 UTC (Fri) by Cato (guest, #7643) [Link] (6 responses)

Unfortunately Go suffers from a severe GC problem on 32-bit architectures, see https://groups.google.com/forum/#!topic/golang-nuts/qxlxu... (bug 909) for details.

This means that many people can't really use it for long-running 32-bit desktop or server apps, including on smaller VPSs that may be 32-bit since they only need 1 or 2 GB RAM.

The next 20 years of Python

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

twenty years from now you will only find 32-bit architectures in museums, so i'm not sure why you are bringing this up (everyone who works with go has heard it numerous times before and rightly sees it as a nonissue)

The next 20 years of Python

Posted Jul 13, 2013 9:12 UTC (Sat) by Cato (guest, #7643) [Link]

For people who have to build 32-bit apps now, this could be a real issue so it's worth flagging it. However, it seems to have been solved to some extent since I last looked at it.

The next 20 years of Python

Posted Jul 14, 2013 8:02 UTC (Sun) by dlang (guest, #313) [Link]

you mean like there are no 8 bit architectures being used any longer?

ohh, I guess you haven't heard that there are more 8 bit processors being built and sold today than ever before, far more 8 bit processors are sold than 32 bit processors.

Now, it's true you don't see general purpose computers being sold with 8 bit processors any longer, but that's not the same as "only found in museums"

The next 20 years of Python

Posted Jul 13, 2013 8:57 UTC (Sat) by lab (guest, #51153) [Link] (2 responses)

To be fair, this problem appears to be chipped away at consistently, and should already be much less of a problem than it has been. Quoting from http://code.google.com/p/go/issues/detail?id=909#c59 :

"For a problem of this generality, "fixed" is a difficult word. The core problem is that the garbage collector is not fully precise. This can cause a value that does not contain a pointer to appear to be a pointer, which prevents the garbage collector from collecting the memory block to which the non-pointer appears to point. In practice this happens most often with floating point values; integers rarely appear to be pointers, but floating point value sometimes do.

So much for the background. In Go 1.1 the GC is far more precise than the GC in Go 1.0. That means that these sorts of problems are vastly less likely to occur when using Go 1.1 than they are with Go 1.0. In particular in Go 1.1 the heap is almost entirely precisely typed, and floating point values in the heap will never be mistaken for pointers.

However, the problem is not entirely fixed because even in Go 1.1 the GC is not entirely precise. In particular in Go 1.1 stack frames are not precisely typed. So if, for example, you have a bunch of floating point local variables, those variables can appear to be pointers while the function is live and cause the GC to fail to collect various memory blocks. This is not likely to be a problem for most programs, but it is certainly possible.

In Go 1.2 the GC will be even more precise than it is in Go 1.1. On tip the GC is already precise for function arguments and results. Go 1.2 may be precise for local variables on the stack. It may even be fully precise. But it's too early to tell whether this work, which is ongoing, will be complete for Go 1.2.

So the current status is that most programs that did not work with Go 1.0 should now work fine with Go 1.1. However, it is possible to construct test cases that will not work well with Go 1.1. And there is a very small chance that your real program will accidentally happen to be one of those test cases. But it's a very small chance. Also, if you are so unfortunate as to encounter that chance, you do have options in Go 1.1 that you did not have in Go 1.0: you can force your non-pointers that appear to be pointers off the stack into the heap. That will give you a bit more heap allocation, but in return the GC will collect more data."

The next 20 years of Python

Posted Jul 13, 2013 9:15 UTC (Sat) by Cato (guest, #7643) [Link] (1 responses)

Thanks for this useful clarification - seems like progress is being made to fix this.

In the short term, it may be enough for server apps on 32-bit to just restart after a number of transactions, or a period of time.

It's a bit harder to do such restarts on desktops when user is using the app - however, desktop app restarts are not so uncommon due to software updates, so perhaps a minor update could be pushed forcing an app restart.

The next 20 years of Python

Posted Jul 13, 2013 9:28 UTC (Sat) by lab (guest, #51153) [Link]

It would seem that for the vast majority of programs one should not even have to consider doing restarts, or taking other special measures. In other words: "It should just work now" (with Go 1.1 at least). Of course, when deploying a longrunning program written in *any* language, it will always be prudent to monitor it's behaviour, at least in the beginning, to see whether there are any problems or not. In other other words: There should no longer be any special reasons, to have special worries about Go programs. But as always, check it anyway.

The next 20 years of Python

Posted Jul 12, 2013 18:32 UTC (Fri) by MKesper (subscriber, #38539) [Link] (2 responses)

Python has types, even strong typing, since the beginning.
And what's the point of static typing?

The next 20 years of Python

Posted Jul 12, 2013 19:14 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

The problem is that you need to run the program to find problems with your types and 100% runtime coverage isn't exactly a common thing. How likely is something like this[1] in Python versus Haskell?

[1]http://r6.ca/blog/20120708T122219Z.html

The next 20 years of Python

Posted Jul 13, 2013 9:43 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

Static typing causes a whole category of defective programs to fail at parse-time instead of at an arbitrary moment in execution.

Go

Posted Jul 12, 2013 18:56 UTC (Fri) by yodermk (subscriber, #3803) [Link] (9 responses)

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.

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:

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.
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.

The next 20 years of Python

Posted Jul 14, 2013 15:25 UTC (Sun) by man_ls (guest, #15091) [Link] (2 responses)

that said, i think the glory days of the 90s scripting language are over.

Actually, JavaScript is the cool thing of the day between kids and Java refugees. Big enterprises are rewriting server stacks because of the flexibility JavaScript offers.

I seriously doubt scripting languages are now worse than they ever were. I count 7 scripting languages in GitHub top 10 languages.

The next 20 years of Python

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

This is caused by GitHubs users, and is not representative of the overall developer population.

Developer surveys

Posted Jul 14, 2013 22:41 UTC (Sun) by man_ls (guest, #15091) [Link]

The TIOBE software index shows five scripting languages in the top 10, although their positions are lower than in GitHub.

If you have a wider survey that shows current trends any please share it.