31–40 of 463 posts
It seems interesting but my concern is that it's just another Unladen Swallow.
They also have the benefit of being able to push features into the Go core that they might need for this.
Very interesting project and technical solution. Is this in use at Google? The described example problem is Youtube with millions of requests per second, but the post doesn't say if it Grumpy was put in production (and what performance gains were then achieved).
Just tried this out on a reasonably complex project to see what it outputs. Looks like it only handles individual files and not any python imports in those files. So for now you have to manually convert each file in the project and put them into the correct location within the build/src/grumpy/lib directory to get your dependencies imported. Unless I missed something somewhere.. The documentation is a bit sparse.
Overall I think the project has a lot of potential and I'm hoping it continues to be actively developed to smooth out some of the rough edges.
This seems like an odd engineering choice. Presumably the effort to create a python->go translator would be non-trivial. Why not just start rewriting components into Go, and migrating them out of Python, leaving python as essentially the presentation layer at most?
This actually pretty great. Even if you will never run your code in grumpy, it underlines the status of Python. Having large corps investing in Python will help pulling in new talent into the Python environment also it strengthens the ecosystem of Python.
Not exactly an endorsement.
Sadly, the code was just dumped into a new Git repo, so no way to tell how many people contributed internally so far.
Python needs a new runtime. This talk shows how bad of shape it's really in. https://www.youtube.com/watch?v=qCGofLIzX6g&list=PLRdS-n5seL... Basically, the language doesn't have a "spec" per-se. The language is whatever the defacto CPython implementation happens to do within it's giant eval loop. Another great talk about CPython internals: http://pgbovine.net/cpython-internals.htm
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 cpython is the reference implementation it values code clarity over performance optimisation.
Here's a great article from a couple of years ago by Chris Seaton on this topic.
I wonder why the Grumpy Fibonacci is so much slower than CPython for 1 thread. Seems weird given Grumpy is compiled.
I am not sure, any implementation of Python will beat the single threaded performance of Cpython..