Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grumpy: Go running Python

opensource.googleblog.com

Post reply on HN
Print view View original

441–450 of 463 posts

Re: Grumpy: Go running Python

#441

Post by jwillp »

kibwen wrote: post #275
derefr wrote: post #235

Earlier quoted context omitted.

> I don't know that this makes sense for anyone but Google I'm not sure; as a Go developer, I kind of like the idea of having access to the Python library ecosystem from Go, without being forced to create an IPC bridge and building up the requisite release-management and deploy-time goop. Plus, I'm just not a Python developer; in the case where the only library that exists to do something is written in Python, I'd mu…

> I kind of like the idea of having access to the Python library ecosystem from Go I'd like to see an example of this, because from the blog post I get the impression that this mostly allows accessing the Go ecosystem from Python, rather than the other way around. For example, how would Python classes be handled from Go?

embed a cpython interpreter into the Go runtime as an embedded interpreter?

Re: Grumpy: Go running Python

#442

Post by jwillp »

coldtea wrote: post #362
orf wrote: post #308

Earlier quoted context omitted.

It's mainstream for new projects. Which is what was expected and aimed for.

Citation needed. Most companies I know that have 2.7 older projects also do new projects in 2.7. They don't want to introduce 2 different versions of the language, set of dependencies etc to their production.

absolutely true. imagine porting a decade or more of code for only the promised benefit of a more "pure" language. asyncio is nice, but excluding it and enhanced generator syntax from 2.7+ is >policymanagement<, not good engineering. The BFDL is fallible. Placeholder looks like a great Python 2.8+ to me. Runs all my old code and gives me new syntax, without rejiggering the stdlib for purity's sake? Twist my arm.

Re: Grumpy: Go running Python

#443

Post by mathw »

quotemstr wrote: post #411
mathw wrote: post #389

Earlier quoted context omitted.

Mmm, "faster than node.js" isn't a great benchmark out in the wide world. Although node.js being as fast as it is remains an astonishing thing.

Who cares about the speed of the interpreter? The interpreter's job is to orchestrate high-performance components written in some high-performance language. If your interpreter is dominating execution time, you should move some of your logic to native code.

Well... yes. That's basically my point. Comparing speed to node.js is pretty much useless because if you really care about speed you're not using node in the first place.

Re: Grumpy: Go running Python

#444

Post by therein »

tedmielczarek wrote: post #193
poooogles wrote: post #59

Earlier quoted context omitted.

>- Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. Python 2.7 is what's running at Google. Not really surprising they're looking at this considering the fast approaching end of (core dev) support for Python 2.7. Write an interpreter in another language and programatically port modules to Go. Seems pretty sensible to me.

Given the failure of their unladen-swallow work to make it into CPython, I think Google is probably tired of trying to make Python faster. Some of their stated goals with Go were to be a faster, compiled Python, so this makes a lot of sense for their use case. They face the choice of fixing all their existing Python code to run in Python 3 (which won't make anything faster), or just porting everything to a different…

Statically linked Python interpreter sounds pretty great to be honest.

Re: Grumpy: Go running Python

#445

Post by [deleted] »

tedmielczarek wrote: post #193
poooogles wrote: post #59

Earlier quoted context omitted.

>- Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. Python 2.7 is what's running at Google. Not really surprising they're looking at this considering the fast approaching end of (core dev) support for Python 2.7. Write an interpreter in another language and programatically port modules to Go. Seems pretty sensible to me.

Given the failure of their unladen-swallow work to make it into CPython, I think Google is probably tired of trying to make Python faster. Some of their stated goals with Go were to be a faster, compiled Python, so this makes a lot of sense for their use case. They face the choice of fixing all their existing Python code to run in Python 3 (which won't make anything faster), or just porting everything to a different…

[deleted]

Re: Grumpy: Go running Python

#446

Post by wrsh07 »

xordon wrote: post #434
wrsh07 wrote: post #177

Earlier quoted context omitted.

For my money, a better C++ is in development: it's called C++20.

C++ with more stuff isn't the same as "better C++". C++ has more features than any one person could ever need and it seems like the design philosophy is: anything that is possible in any language; should be added to C++. In reality it is a huge problem for productivity.

If you think that languages iterate simply to add stuff, I don't think you understand language development as well as you think.

Maybe you're being glib, and that's fine. But improving build times, metaprogramming (which greatly simplifies many libraries), adding lazy ranges, more powerful type inference, better error messages - these are all improvements.

The fact is, better metaprogramming means c++ gets smaller, because you don't have to learn separate languages for run time vs compile time computation.

If you think the development of c++ in the past few years is anything short of amazing, you're quite mistaken.

Re: Grumpy: Go running Python

#447

Post by webmaven »

trotterdylan wrote: post #82
paulsmith wrote: post #44

Earlier quoted context omitted.

Who says CPython is not well-optimized? CPython is 25 years old -- people have been making it faster for a long time. Python 3.6, the latest release, has many performance improvements, cf. http://www.infoworld.com/article/3120952/application-develop...

Interestingly, achieving performance parity with CPython is one of the biggest challenges of this project. There are certain things CPython does very fast like allocating and freeing many small objects.

So, Grumpy currently isn't faster than CPython?

Re: Grumpy: Go running Python

#448

Post by webmaven »

jamestimmins wrote: post #159

Does anyone know if there is an easy way to get involved in open source projects like this? The readme mentions adding PRs, but as someone that doesn't have much experience working with open source projects like this, I don't even know where to begin. It sounds like an incredible learning opportunity though.

Check out OpenHatch: https://openhatch.org/

Re: Grumpy: Go running Python

#449

Post by webmaven »

walrus1066 wrote: post #369

Question: better threading performance seems to be the main motivation for this project. Could they not just use multiprocessing instead of threading for the cpu-heavy parts of the YouTube codebase, and threading or asyncio for the io-bound parts of it? Edit: for example, the fib benchmark they cite is cpu-bound. If the python code used multiprocessing, the performance would scale almost linearly with the number of p…

> Could they not just use multiprocessing instead of threading for the cpu-heavy parts of the YouTube codebase, and threading or asyncio for the io-bound parts of it?

Probably, but consider how much bare iron Google has lying around, much of it likely with few cores-per-CPU. Using it efficiently and not accelerating it's obsolescence is probably a priority for them.

BTW, does anyone have data that would suggest how long it does take an org at the scale of an Amazon, Google, or Facebook to entirely replace their HW? I assume that it isn't only through attrition, and that Google for example currently has no servers running that date back to Y2k, but I have no idea what the "half-life" of a server is at their scale.

Re: Grumpy: Go running Python

#450

Post by webmaven »

brettcannon wrote: post #126
rpedela wrote: post #35

How does Grumpy handle Decimal in Python? As far as I am aware there isn't an equivalent in Go.

The decimal module in Python 2.7 is implemented in pure Python: https://github.com/python/cpython/blob/2.7/Lib/decimal.py (in Python 3 there is an accelerated extension module that's used when available, falling back on the pure Python version otherwise).

So, does Decimal work with Grumpy (you're implying it does)?

For that matter, does Grumpy match CPython's Float behavior exactly?

ie.:

    >>> 2.2 + 3.1
    5.300000000000001
    >>>
Post reply on HN