Become a fan of Slashdot on Facebook


Forgot your password?
Google Python Programming

Google Boosts Python By Turning It Into Go ( 129

An anonymous reader quotes InfoWorld: Grumpy, an experimental project from Google, transpiles Python code into Go, allowing Python programs to be compiled and run as static binaries using the Go toolchain... In a blog post announcing the open source release, Google stated the project stemmed from its efforts to speed up the Python-powered front end for YouTube. But Google hit an obstacle that's familiar to folks who've deployed Python in production: It's hard to get CPython -- the default Python interpreter written in C -- to scale efficiently. "We think Grumpy has the potential to scale more gracefully than CPython for many real world workloads," writes Google...

Because it doesn't support C extensions, Grumpy doesn't have CPython's Global Interpreter Lock, which is commonly cited as a roadblock to running Python concurrent workloads smoothly. Grumpy also uses Go's garbage collection mechanisms to manage memory under the hood, instead of CPython's. Grumpy creates close interoperation between Python and Go by allowing Go packages to be imported and used with the same syntax as Go modules.

This discussion has been archived. No new comments can be posted.

Google Boosts Python By Turning It Into Go

Comments Filter:
  • by Anonymous Coward

    A Python eating its tail and forming a wheel, making it Go easier.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      I think the ouroboros symbols is used by PyPy (JIT compilation):

  • by Anonymous Coward

    What are they talking about? Stop inventing new shit all the fucking time, and just fucking stick to what fucking works and is stable. You never let anything settle. You constantly crave change for the sake of change. Fuck off. Slow the fuck down. My Windows 10 hasn't even updated to Anniversary Edition yet, and there are already multiple major updates since. It's insanity. Stop changing everything. Go back to the UI of Windows 95 and start over from there. Stop making new programming languages. Stop doing

  • by Anonymous Coward

    1. parse python into AST.
    2. reformat with curly braces.
    3. take over the world; there would be no stopping a curly-braces version of python.

  • by CQDX ( 2720013 ) on Sunday January 08, 2017 @02:25AM (#53627127)

    Python's GIL. Pythonistas keeping pushing for Python everywhere but don't realize that Python does have its limits and is not the language of choice if you need performance on multiple cores. In my experience, when you try to emulate multithreading in Python using some message passing scheme you end up with something that is more complicated, harder to debug and tune, harder to maintain, than the equivalent written in good C++.

  • Well COBOL has both funky syntax rules and scalability. Nearly there guys!
  • Try JPython (Score:5, Insightful)

    by aberglas ( 991072 ) on Sunday January 08, 2017 @03:35AM (#53627285)

    It should use the Java JIT compiler to run much faster than any byte code interpreter.

    That said, I do not know why anybody would even think of using a programming language without static typing. Not for performance, but rather for sanity when writing and (more importantly) maintaining code. With type inference it costs virtually no extra typing.

    • by Anonymous Coward

      Good point. I was thinking about the all the discussions of Rust. It seems Rust is just "reinventing" Ada. Used to code in Ada, great language for writing quality robust code. Static typing is a good thing.

      • by DrXym ( 126579 )
        I think Rust does have some similarities to Ada in terms of its design goals and even some of its syntax (match vs case for example). But it is designed to replace C / C++ code and so the syntax is fairly C-like - curly braces, semi-colons etc. The main thing it tries to do is enforce safety upfront at compile time so that only "correct" code gets through and is therefore not vulnerable to the ubiquitous errors of C / C++ - memory leaks, dangling pointers, buffer overruns, data races etc.

        I've played aroun

    • Re:Try JPython (Score:4, Informative)

      by yithar7153 ( 4137793 ) on Sunday January 08, 2017 @08:44AM (#53627781)
      Yeah, this is why I love OCaml. OCaml has static typing with type inference. You don't have to type the types out if you don't want to, but you still get those strong guarantees at compile time because of mathematical proofs.

      My compilers professor said that he believed that type systems are the most important form of program verification that we have (See notes []).
      • by ndykman ( 659315 )

        Type checking is ultimately formal verification (see the Curry-Howard correspondence). Of course, this limits what type systems can specify about a program, and practically, the restrictions placed on languages based on certain more advanced type systems greatly limit their use in general programming.

    • Nitpicking, buy it was JPython in 1997
      It has been Jython since 1999 []

      > I do not know why anybody would even think of using a programming language without static typing.

      - Dynamically typed programming languages are more productive when writing smaller quantities of rapidly evolving code.

      - It is mainly a library and an ecosystem issue. Python tends to have all the modules I need, while Haskell, OCaml and Scala often don't... and they often seem to be much easier to pick up an

    • by sjames ( 1099 )

      Static typing is a special case of contract capabilities/attributes. It's used because it's easier, but form a theoretical standpoint, you don't want to demand that the object be a "customer", you want to demand that it has a mailing address attribute accessed as .mailing_address. Ideally it should not lose it's "Employee-ness" if it gets passed in, in case a later step needs to special case that or take some extra action if the object is_A or better yet, has_A...

      Python is an experiment in that with Duck Ty

  • by ooloorie ( 4394035 ) on Sunday January 08, 2017 @11:54AM (#53628307)

    There have already been several excellent implementations of Python that compile to native code, either via JIT or directly, including IronPython. But Python's performance problems aren't in Python code, since anything compute intensive is done in native libraries. The real problem with all of those implementations is that, like Grumpy, they don't have native, thread-safe libraries, foremost Numpy and Scipy.

    Grumpy sounds like an attempt to migrate Python users to Go. That's probably the right idea, because Python seems to be going nowhere fast. Go, however, is probably not the right language to migrate to, despite its moderate adoption in some systems applications, mostly because Go just gives the finger to existing programming practice for no other reason than FYTW.

  • I like that these languages all bring new ideas and are a great learning opportunity; erlang and go have interesting programming models and CSP/actor functionality. But I feel I should be able to enjoy these things in other languages after they have a while to get absorbed, that's not generally the case though, for example I've been reading about using akka in java for a while now and the syntax looks clumsy to my eye compared with erlang and I've totally failed to get my head around scala.

    same thing with i

    • erlang gives you nothing that couldn't be done in many other languages. Bad to start a project using niche language when other languages have rich set of libraries, large talent pool for hiring, and many personnel in house for maintenance. erlang has none of the above. immature to get infatuated with the "shiny", real world doesn't want it.

  • Instead of translating to Go, why not directly translate to C, or even to language machine?

    • by snadrus ( 930168 )

      Go's (initially) looks quite Python-like in terms of packages and memory concepts. Also message-passing is the main mechanism of concurrency.
      But Python's power (as well as its woes) comes from the C extensions & GIL. So to get rid of the GIL (required for serious Python performance) you've got to have a fast language replacing it that libraries can be written in that cross calls.

      The language for this would also do best to resemble Python to begin with. Go seems like a most logical fit here.

      SciPy & N

  • How is this different from what Cython has been doing for years? There's nothing new about the idea of translating Python to a statically compiled language to improve performance.

Federal grants are offered for... research into the recreation potential of interplanetary space travel for the culturally disadvantaged.