[Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

[Nick Coghlan]

On 29 May 2015 2:16 am, "Barry Warsaw" <barry at python.org> wrote:
>
> Go seems to be popular where I work.  It is replacing Python in a number
of
> places, although Python (and especially Python 3) is still a very
important
> part of our language toolbox.
>
> There are several reasons why Go is gaining popularity.  Single-file
> executables is definitely a reason; it makes deployment very easy, even
if it
> increases the maintenance burden (e.g. without shared libraries, you have
> multiple copies of things so when a security fix is required for one of
those
> things you have to recompile the world).
>
> Start up times and memory footprint are also factors.  Probably not much
to be
> done about the latter, but perhaps PEP 432 can lead to improvements in the
> former.  (Hey Nick, I'm guessing you'll want to bump that one back to
3.6.)

Yep. I got the feature branch mostly working again just after PyCon (since
several folks expressed interest in helping with it), and thanks to Eric
Snow, the biggest blocker to further progress (splitting the import system
initialisation into two distinct phases) has already been addressed for 3.5
(that's not merged into the feature branch in my sandbox repo yet, though).

PEP 432 itself isn't likely to change startup time for the full interpreter
runtime very much (as it's mostly about rearranging how we call the
existing setup steps, rather than changing the steps themselves), but
having more of the C API available earlier in the bootstrapping cycle will
hopefully lay a foundation for future improvements.

The intent is also to make embedding *much* easier, and have it be trivial
to skip initialising any subsystems that a given application doesn't need.

> Certainly better support for multi-cores comes up a lot.  It should be a
SMoE
> to just get rid of the GIL once and for all <wink>.

Eric's been looking into this as well, and we think there's a plausible
path forward based on changing the way subinterpreters work such that the
GIL can be changed to a read/write lock, and each subinterpreter gets its
own Local Interpreter Lock.

Expect to hear more on that front before too long :)

> One thing I've seen more than once is that new development happens in
Python
> until the problem is understood, then the code is ported to Go.  Python's
> short path from idea to working code, along with its ability to quickly
morph
> as requirements and understanding changes, its batteries included
philosophy,
> and its "fits-your-brain" consistency are its biggest strengths!

Right, Go is displacing C/C++ in that regard (moreso than Python itself),
and now that Rust has hit 1.0, I expect we'll see it becoming another
contender for this task. Rust's big advantage over Go in that regard is
being compatible with the C/C++ ecosystem, including Python's cffi.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150529/fa60ca57/attachment-0001.html>