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

201–210 of 463 posts

Re: Grumpy: Go running Python

#201

Post by trotterdylan »

statsmatscats wrote: post #150
trotterdylan wrote: post #140

Earlier quoted context omitted.

I'd like to support 3.x at some point. See https://github.com/google/grumpy/issues/1

Have you thought about using type hints to help type inference? Some work on that is discussed here. I would love a dropbox google colab (though also targeting 3.x :) ) https://github.com/python/mypy/issues/1862

Yes, leveraging type hints for optimization purposes is a long term goal. Thanks for pointing me to that issue, I'll keep an eye on it.

One of the goals of open sourcing was to get feedback and work with outside folks so I'm definitely open to collaboration!

Re: Grumpy: Go running Python

#202

Post by tedmielczarek »

Antwan wrote: post #153

"So we asked ourselves a crazy question: What if we were to implement an alternative ?" As always with Google... What if you humbly contribute to open source projects rather than creating new stuffs, labelled with your own brand, controlled by your own engineers, and with your own design choices, however good they may be ?

They tried that with CPython, it didn't work: https://www.python.org/dev/peps/pep-3146/

Re: Grumpy: Go running Python

#203

Post by kj01a »

cdelsolar wrote: post #110
BuckRogers wrote: post #103

Earlier quoted context omitted.

Python3 was never the future of Python. It never got over the hump all new languages need to if attempting to reach relevance. It's likely code using lots of C-extensions will continue with CPython2 and new code will be written in Grumpy (pure Python2).

That is pretty ridiculous. Pretty much all major libraries are Python 3 compatible and everyone is writing Python 3 (or should be). (Yes, I'm still on Python 2 but moving soon).

>(Yes, I'm still on Python 2 but moving soon).

I'm like really new to programming and I'm still just learning the basics, but I see this little addendum a lot from people who say everyone should be writing Python 3.

Re: Grumpy: Go running Python

#204

Post by lima »

coldtea wrote: post #156
dbaupp wrote: post #148

Earlier quoted context omitted.

Which numbers? People keep saying things like that, but things like the Python 3 Wall of Superpowers https://python3wos.appspot.com/ don't seem to support it. Do you have something more concrete?

The "Wall" is just numbers for Python3, without context for how it compares to Python 2. For 2.7 Pypy reported 419,227,040 downloads for 2016. At the same time, for ALL 3.x versions combined (up to 3.6) there are just: ~52 million downloads. That's 1/8th of the Python 2 downloads.

The PyPy statistics aren't worth much since they're counting all sorts of automated downloads/dependencies/etc.

That's why packages like supervisor and graphite - which aren't libraries - are among the top downloads.

Re: Grumpy: Go running Python

#205

Post by geodel »

curtis wrote: post #171
coldtea wrote: post #134

Earlier quoted context omitted.

> One of my complaints about Go is that it seems to be designed with the (mistaken, in my opinion) notion that what we really need is just a better C. It was designed with the notion that all some people really need is just a better C. For other people there's Swift, Rust, etc.

For better or worse, I think Go sucked up a lot of the metaphorical oxygen for similar languages. Swift and Rust are in different niches and don't compete head to head with Go, so this isn't a real problem for them. What I've long wanted is a better C++ , not a better C. It would be hard for any such language to succeed today, because it will have to compete with Go, and Go has a fairly mature toolchain and widesprea…

I think Go being Google product is overemphasized. Dart is far more a Google product and has achieved modest success in industry.

Rust is putting lot of effort in better marketing because they want much broader usage than bits of high-perf, low level code which cannot tolerate a GC pause.

Similarly Swift is putting effort on general Server side coding. But I think it will remain limited to server side bits of macOS/iOS applications etc.

Re: Grumpy: Go running Python

#206

Post by wolf550e »

pjmlp wrote: post #181
jszymborski wrote: post #139

Earlier quoted context omitted.

I think that that's rather dismissive of a language that runs huge web, scientific, and general purpose applications daily.

It might be, but that it is usually a consequence of not knowing any better or making use of existing libraries. Just like people learned 8-bit BASIC and went on to do business applications and games on it. I went Z80 ASM instead. Personally I would only use Python for shell scripting and advise for using Julia instead. Of course, others see it differently.

Some people are very productive in Django and Rails (and the like), in non-performant languages. Many sites never grow to the size where running on the JVM (or AOT-compiled Go) would save you money from fewer servers vs. more coder-hours.

Re: Grumpy: Go running Python

#207

Post by lima »

Certhas wrote: post #158
coldtea wrote: post #125

Earlier quoted context omitted.

> and everyone is writing Python 3 (or should be) You'd be surprised. If anything, the numbers show the opposite. The vast majority of Python codebases, legacy or new, are 2.7 or older.

There's plenty of 2.7 out there, but we're moving over slowly, basically due to the nice function annotation/type checking work. That's to me the first really compelling reason to use the latter.

Hell, even OpenStack (which is giant tangled mess of code written by like a few dozen teams) is making good progress.

Re: Grumpy: Go running Python

#208

Post by naasking »

trotterdylan wrote: post #116
naasking wrote: post #4

I wonder why the Grumpy Fibonacci is so much slower than CPython for 1 thread. Seems weird given Grumpy is compiled.

Although Grumpy is compiled, it is just as dynamic as Python, in that method dispatch involves dictionary lookups, etc. The main reason why Grumpy's slower for most single threaded benchmarks is that most Python workloads involve creating and freeing a bunch of small Python objects. In Go, these objects are garbage that need to be GC'd in a very general way. In CPython, there are free lists, arenas and other optimiza…

> Although Grumpy is compiled, it is just as dynamic as Python, in that method dispatch involves dictionary lookups, etc.

Right, I suppose I assumed that straightforward numerical-looking code would be translated to Go numerical code. Perhaps they just aren't that ambitious yet.

Re: Grumpy: Go running Python

#209

Post by lima »

paulsmith wrote: post #44
dijit wrote: post #37

Earlier quoted context omitted.

cpython is the reference implementation, so it makes sense that it's; A) Not well optimised. B) Touting features before the spec/standard. EDIT: people really dislike that I said this, and I'm having trouble finding my original citation- it was on one of the many python books I own. Most likely "Learn Python The Hard Way" but I'll dig out the exact chapter where they compare pypy to cpython and mention that because c…

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

Notably, some of the 3.6 performance improvements were merged in from PyPy :-)

Re: Grumpy: Go running Python

#210

Post by lima »

jerf wrote: post #195
goatlover wrote: post #191

Earlier quoted context omitted.

The scientific community thinks otherwise.

The scientific community uses it as a tool to automate specification of tasks to be performed inside of C libraries. It's a case pjmlp may not have explicitly named, but it's of the same kind.

PyPy is making good progress at implementing and JITing numpy as native Python code.
Post reply on HN