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

451–460 of 463 posts

Re: Grumpy: Go running Python

#451

Post by Volt »

hellofunk wrote: post #352
Pxtl wrote: post #251

I can't help but see this balkanization of Python as a sign that the core language is falling apart. How many interpreters are there now? And how many of them have even close to 100% compatibility with Python 2.7 or 3.N? Guido has lost control of the language, but has he's still officially the BDFL there's no real standardization body. His stubborn view on functional mechanisms have held the language back syntactical…

Actually, historical evidence suggests the opposite of your argument: multiple implementations of a language typically mean it is succeeding, not failing.

Really then, it suggests that Python 2 is succeeding, not Python 3.

Re: Grumpy: Go running Python

#452

Post by coldtea »

gsnedders wrote: post #268
LeifCarrotson wrote: post #180

Earlier quoted context omitted.

Given that there are only 7.5 billion humans on the planet, and that rather significantly fewer than 1 in 20 people are PyPy-using developers, perhaps those numbers should be taken with a grain of salt? The message I would take from those statistics is that needing a fresh download of Pypy is less common among 3.x users than among 2.7 users, who apparently needed to reinstall from the web at least a few times a day d…

It should be PyPI rather than PyPy in the parent, FWIW.

Oops, mea culpa.

Re: Grumpy: Go running Python

#453

Post by webmaven »

tedmielczarek wrote: post #435
teddyh wrote: post #363

Earlier quoted context omitted.

But it was no fault of Python: https://qinsb.blogspot.nl/2011/03/unladen-swallow-retrospect...

Interesting, I hadn't seen that post! I wonder if there are any posts that elaborate on the internal Google bits more. I'd love to know what "they found other ways to solve their performance problems" wound up meaning in practice.

> I'd love to know what "they found other ways to solve their performance problems" wound up meaning in practice.

Me too, especially as this was already several years after the YouTube acquisition.

Also interesting to note that potential internal customers were put off by having to upgrade to 2.6.1 in order to use unladen-swallow (presumably they got over that reticence at some point, as 2.7 is now standard).

Re: Grumpy: Go running Python

#456

Post by brettcannon »

webmaven wrote: post #450
brettcannon wrote: post #126

Earlier quoted context omitted.

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

I'm implying that they can get the decimal module into Grumpy by implementing enough of Python to support the module (i.e. they don't need to implement the decimal module from scratch because the module isn't implemented only in C).

Re: Grumpy: Go running Python

#457

Post by orf »

pjmlp wrote: post #428
orf wrote: post #406

Earlier quoted context omitted.

> Scala, Clojure, F# Functional languages. The "year of Linux on the desktop" of programming languages. Also none of those look like pseudocode (Scala does if you ignore bits and squint).

The amount of job postings say otherwise.

No they don't. On stack overflow jobs F# has 14 posts, closure 28 and Scala ~100. Python has 400+.

Other sites have similar totals. But they are filtering for London/UK/Europe, so that might be a bias.

Re: Grumpy: Go running Python

#458

Post by webmaven »

brettcannon wrote: post #456
webmaven wrote: post #450

Earlier quoted context omitted.

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

I'm implying that they can get the decimal module into Grumpy by implementing enough of Python to support the module (i.e. they don't need to implement the decimal module from scratch because the module isn't implemented only in C).

Got it. Thanks for the clarification, Brett.

Re: Grumpy: Go running Python

#459

Post by djm_ »

pjmlp wrote: post #382
djm_ wrote: post #306

Earlier quoted context omitted.

>Google essentially is moving everything to Go ...[snip]... and then module by module will rewrite it in pure Go. I can see this happening for some core modules sure, but I think you've underestimated the work required to convert the sheer amount of Python code at Google. There is a tool inside Google which graphs the number of lines of each language in Piper; I don't think I can quote numbers from my time there but…

It just needs to happen one piece at a time, even if it takes a few years.

s/years/decades, then sure.

Re: Grumpy: Go running Python

#460

Post by JPKab »

pjmlp wrote: post #405
orf wrote: post #402

Earlier quoted context omitted.

> there are alternatives like LANPACK and BLAS. LANPACK + BLAS = scipy > Numpy/Scipy are only relevant to a minor set of computer users.. > ... Java and .NET ... Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages.

> LANPACK + BLAS = scipy Thanks, I already knew that. > Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages. Hence we are back at Scala, Clojure, F#, enjoying the respective AOT/JIT native code compilers, and integrating with that highly-optimized C/Fortran code.

I use Scala and Clojure. I like F#. Have you ever worked at an actual business that needs to hire developers that know these languages WELL? I can tell you that the significant added cost can't be justified by the not-very-big benefits compared to just using Scipy.
Post reply on HN