TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Grumpy: Go running Python

1411 点作者 trotterdylan超过 8 年前

58 条评论

Animats超过 8 年前
- Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out.<p>- It&#x27;s a hard-code compiler, not an interpreter written in Go. That implies some restrictions, but the documentation doesn&#x27;t say much about what they are. PyPy jumps through hoops to make all of Python&#x27;s self modification at run-time features work, complicating PyPy enormously. Nobody uses that stuff in production code, and Google apparently dumped it.<p>- If Grumpy doesn&#x27;t have a Global Interpreter Lock, it must have lower-level locking. Does every built-in data structure have a lock, or does the compiler have enough smarts to figure out what&#x27;s shared across thread boundaries, or what?
评论 #13320522 未加载
评论 #13320520 未加载
评论 #13321847 未加载
评论 #13320535 未加载
评论 #13321303 未加载
评论 #13323638 未加载
评论 #13320539 未加载
评论 #13320500 未加载
评论 #13322268 未加载
epanastasi超过 8 年前
As someone who works on both python and go day to day, I find this to be quite interesting.<p>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&#x2F;src&#x2F;grumpy&#x2F;lib directory to get your dependencies imported. Unless I missed something somewhere.. The documentation is a bit sparse.<p>Overall I think the project has a lot of potential and I&#x27;m hoping it continues to be actively developed to smooth out some of the rough edges.
评论 #13320631 未加载
评论 #13320533 未加载
评论 #13320593 未加载
jerf超过 8 年前
For those who are interested, I&#x27;ve used grumpy to compile the following Python code and placed it at <a href="https:&#x2F;&#x2F;play.golang.org&#x2F;p&#x2F;YP1SP7WsdR" rel="nofollow">https:&#x2F;&#x2F;play.golang.org&#x2F;p&#x2F;YP1SP7WsdR</a> . (Note the playground can&#x27;t run this, it just had convenient formatting support for Go; the generated source wasn&#x27;t 100% gofmt compliant.)<p><pre><code> class Test(object): def __init__(self, value): self.value = value def method(self): print(self.value) class Test2(Test): pass t = Test(&quot;hello&quot;) t.method() </code></pre> Pythonistas, note I had to have &quot;class Test(object):&quot; and not just &quot;class Test:&quot;. The former compiled successfully into a Go program but that program then failed at runtime with &quot;TypeError: class must have base classes&quot;.
评论 #13320683 未加载
评论 #13320888 未加载
评论 #13322412 未加载
Pxtl超过 8 年前
I can&#x27;t help but see this balkanization of Python as a sign that the core language is falling apart.<p>How many interpreters are there now? And how many of them have even <i>close</i> to 100% compatibility with Python 2.7 or 3.N? Guido has lost control of the language, but has he&#x27;s still <i>officially</i> the BDFL there&#x27;s no real standardization body. His stubborn view on functional mechanisms have held the language back syntactically, breaking BC with Python 3 without fixing the language&#x27;s fundamental problems... it really feels like Python is lost in the desert.<p>Which doesn&#x27;t mean the language is dead, but it&#x27;s rudderless. I think we were all hopeful when Guido joined Google that we&#x27;d see real direction for Python, but that obviously didn&#x27;t happen.<p>Not that Python is <i>dead</i>, obviously - still lots of great projects are written in Python. But I don&#x27;t like the language&#x27;s future.
评论 #13322358 未加载
评论 #13322355 未加载
评论 #13325045 未加载
评论 #13322403 未加载
评论 #13326510 未加载
ericfrederich超过 8 年前
Python needs a new runtime. This talk shows how bad of shape it&#x27;s really in.<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=qCGofLIzX6g&amp;list=PLRdS-n5seLRqszBqVDF342RMlCWgOTm6q&amp;index=11" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=qCGofLIzX6g&amp;list=PLRdS-n5seL...</a><p>Basically, the language doesn&#x27;t have a &quot;spec&quot; per-se. The language is whatever the defacto CPython implementation happens to do within it&#x27;s giant eval loop.<p>Another great talk about CPython internals:<p><a href="http:&#x2F;&#x2F;pgbovine.net&#x2F;cpython-internals.htm" rel="nofollow">http:&#x2F;&#x2F;pgbovine.net&#x2F;cpython-internals.htm</a>
评论 #13321133 未加载
评论 #13321358 未加载
评论 #13320352 未加载
sfifs超过 8 年前
The main reason I moved from coding in Python to Go as my main language many years back is because concurrency was such a pain in standard Python (the other was compile time error checking).<p>It&#x27;s interesting to see the same pain has now made caused the runtime itself to be implemented in Go.<p>It&#x27;s a pity C extensions (often used in scientific computing) are not supported but Go does have support via CGO, so maybe some approach can be worked out to access C routines in the future.
评论 #13320741 未加载
评论 #13320487 未加载
评论 #13320480 未加载
评论 #13320897 未加载
oblio超过 8 年前
It seems interesting but my concern is that it&#x27;s just another Unladen Swallow.
评论 #13320665 未加载
评论 #13320329 未加载
评论 #13321909 未加载
评论 #13330179 未加载
zigzigzag超过 8 年前
How does this compare to Jython? The blog post says they looked at alternative runtimes but didn&#x27;t like that they had tradeoffs (implying that Grumpy has no tradeoffs??). But Jython has been around for quite a while and also has no GIL:<p><a href="http:&#x2F;&#x2F;www.jython.org&#x2F;jythonbook&#x2F;en&#x2F;1.0&#x2F;Concurrency.html" rel="nofollow">http:&#x2F;&#x2F;www.jython.org&#x2F;jythonbook&#x2F;en&#x2F;1.0&#x2F;Concurrency.html</a><p>It can also handle Python&#x27;s dynamic aspects.
评论 #13321184 未加载
naasking超过 8 年前
I wonder why the Grumpy Fibonacci is so much slower than CPython for 1 thread. Seems weird given Grumpy is compiled.
评论 #13320908 未加载
评论 #13320360 未加载
评论 #13320260 未加载
评论 #13320271 未加载
评论 #13320261 未加载
ot超过 8 年前
There&#x27;s no mention of whether Grumpy passes the CPython test suite. Until it doesn&#x27;t, it&#x27;s not a Python runtime, it&#x27;s a compiler for a language with Python-like syntax.<p>Compilers like this, from almost-Python to say C&#x2F;C++, have existed for a while: Cython, Shedskin, Nuitka are some examples.
评论 #13320537 未加载
评论 #13328131 未加载
Twirrim超过 8 年前
This seems like an odd engineering choice. Presumably the effort to create a python-&gt;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?
评论 #13320248 未加载
评论 #13321126 未加载
评论 #13320345 未加载
评论 #13320739 未加载
评论 #13320588 未加载
评论 #13320215 未加载
评论 #13322004 未加载
评论 #13320223 未加载
评论 #13320236 未加载
评论 #13320279 未加载
评论 #13320280 未加载
theandrewbailey超过 8 年前
This seems like a win for Go, at least to me.<p>I wrote a random sentence generator in Python several years ago. A bit later, I wrote my blog using Java EE. Early on, I had an idea: put that generator in Jython, and spit out a random sentence on every request. It&#x27;s probably the one feature that I was OK to let go, should I switch platforms.<p>Since Oracle has only gotten more evil and Java more stagnant over the years (especially in light of TLS features), I&#x27;ve been thinking of possible alternatives. I&#x27;ve been intrigued by newer compiled languages, and it&#x27;s come down to either Go or Rust, but I&#x27;ve yet to dig too far into them. I might have a winner.
bootload超过 8 年前
<i>&quot;The downside is less development and deployment flexibility, but it offers several advantages. For one, it creates optimisation opportunities at compile time via static program analysis.&quot;</i><p>Optimisation. This is a smart move, hard though. A compiler, written well allows the back end to improve the code. So the whole code base can improve with improved analysis.<p><i>&quot;The biggest advantage is that interoperability with Go code becomes very powerful and straightforward: Grumpy programs can import Go packages just like Python modules!&quot;</i><p>Extending Python (youtube codebase) with Go modules. That&#x27;s interesting.
thedjinn超过 8 年前
I&#x27;m curious to why they started this project when there already is low hanging fruit that can speed up Python (e.g. pypy). What makes this better other than to satisfy the inner go-fanboy?
评论 #13321289 未加载
评论 #13321477 未加载
评论 #13320577 未加载
评论 #13320580 未加载
gamesbrainiac超过 8 年前
In case anyone wanted the github repo: <a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;grumpy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;grumpy</a>
aibottle超过 8 年前
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.
评论 #13320351 未加载
scrollaway超过 8 年前
That looks like a super interesting runtime. Seems to target 2.7 only, I hope they&#x27;re open to supporting 3.x as well.
评论 #13320997 未加载
评论 #13320266 未加载
teabee89超过 8 年前
From looking in the code, this is my favorite part so far: <a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;grumpy&#x2F;blob&#x2F;75a35b4b30afb049b9cfff756bfd6ad6f805a5a7&#x2F;runtime&#x2F;core.go#L666" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;grumpy&#x2F;blob&#x2F;75a35b4b30afb049b9cfff...</a> making python threads as lightweight as goroutines must be a breeze!
agentgt超过 8 年前
* I would love to know how big the codebase is.<p>* It seems like writing a translator to deal with all the use cases is so much more work and risky than iteratively rewriting portions (in whatever faster more concurrent language) and using some form microservice&#x2F;process message passing to communicate with legacy pieces.<p>* Love to know how they compose async operations currently? Is it some sort of object (e.g. Futures, promises, observables, etc)? Is Grumpy going to have some sort of language difference (to Python) to compose async stuff (e.g. async and await)?<p>Of course being biased towards the JVM (since I know it so well) they could get really fast concurrency if they want with Jython today. Most of the Python tools already work with Jython (assuming 2.7).<p>With Jython you could always drop down into Java (or any other JVM lang) if you need more speed as well C for cpython (or even C from Java). It is unclear what you do with Grumpy with performance critical code. Can you interface with Go code or is the plan C?
评论 #13321470 未加载
ohitsdom超过 8 年前
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&#x27;t say if it Grumpy was put in production (and what performance gains were then achieved).
评论 #13320962 未加载
评论 #13320302 未加载
评论 #13320336 未加载
matthewrudy超过 8 年前
I wonder if future work might support C Extensions in the same was as the jruby truffle &#x2F; graal implementation plans to do.<p>Here&#x27;s a great article from a couple of years ago by Chris Seaton on this topic.<p><a href="http:&#x2F;&#x2F;chrisseaton.com&#x2F;rubytruffle&#x2F;cext&#x2F;" rel="nofollow">http:&#x2F;&#x2F;chrisseaton.com&#x2F;rubytruffle&#x2F;cext&#x2F;</a>
bigato超过 8 年前
I see some parallel with the work made to automatically convert Go compiler C code to Go code. Strategically wise, I&#x27;d rather have the software do the transpilation to the new language and then after extensive testing, ditch the old python codebase. But they probably don&#x27;t agree with my preference of Go over Python.
the_duke超过 8 年前
Haha, now that&#x27;s what I call an interesting project.<p>The biggest surprise for me is that the Go runtime would be a good fit for Python, performance wise, considering the very different object and dispatch model.<p>The post also mentions runtime reflection, which used to be painfully slow last time I used it. (Go 1.5, i think).<p>Has this improved in the latest releases?
评论 #13320569 未加载
评论 #13320984 未加载
jamestimmins超过 8 年前
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&#x27;t have much experience working with open source projects like this, I don&#x27;t even know where to begin. It sounds like an incredible learning opportunity though.
评论 #13321709 未加载
评论 #13322878 未加载
评论 #13321812 未加载
评论 #13337197 未加载
quotemstr超过 8 年前
I&#x27;m a bit disappointed that the blog post doesn&#x27;t explain why the authors didn&#x27;t choose PyPy instead.
评论 #13320486 未加载
评论 #13321262 未加载
rpedela超过 8 年前
How does Grumpy handle Decimal in Python? As far as I am aware there isn&#x27;t an equivalent in Go.
评论 #13320955 未加载
0xdeadbeefbabe超过 8 年前
&gt; Once we started going down the rabbit hole, Go seemed like an obvious choice...<p>Good? It&#x27;s funny that a rabbit hole is the place you go to make obvious choices. This culture must seem strange to outsiders.
drej超过 8 年前
It&#x27;s all about performance and concurrency here, but I&#x27;m quite happy about this for another reason: static compilation. If I needed really performant code, I&#x27;d write it in Go&#x2F;Cython&#x2F;[insert your fav language] in the first place. But if I have some existing code that I just want to run without worrying about the Python runtime being installed&#x2F;correct, this is a good solution.<p>(Sure, none of my code will work, because it&#x27;s all Python3 and usually uses C&#x2F;asm, but it&#x27;s still early and I&#x27;m hopefull.)
ericfrederich超过 8 年前
There was also this effort:<p><a href="https:&#x2F;&#x2F;blog.heroku.com&#x2F;see_python_see_python_go_go_python_go" rel="nofollow">https:&#x2F;&#x2F;blog.heroku.com&#x2F;see_python_see_python_go_go_python_g...</a>
sea6ear超过 8 年前
Reminds me of the (old I guess?) ShedSkin project to automatically translate Python to C++.<p>I suppose the easy concurrency and ability to inter-operate with Go libraries is really the driver for Go over that.
评论 #13327177 未加载
curtis超过 8 年前
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.<p>One way to leverage C&#x27;s widespread availability and high-performance while side-stepping some of its deficiencies was simply to use it as a target for a different language. The Cfront C++ compiler which generated C code is probably the most famous example, but I recall that there were many others.<p>Maybe Go, like C, will make a fruitful target for other language implementations.
评论 #13320983 未加载
评论 #13322754 未加载
walrus1066超过 8 年前
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?<p>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 processes.
评论 #13337321 未加载
agounaris超过 8 年前
Whatever the haters say here, this is really cool!
zedpm超过 8 年前
I would love to see this support Python 3.5+, specifically for asyncio. Concurrency via threads in Python is far less appealing.
webmaven超过 8 年前
The code initially landed on Github 16 days ago[0]. How long was it developed internally before that?<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;grumpy&#x2F;commit&#x2F;f60ee257db9d7996e3f8da148260e113516e3a90" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;grumpy&#x2F;commit&#x2F;f60ee257db9d7996e3f8...</a>
cbhl超过 8 年前
The blog post says that YouTube is the inspiration for this runtime, but does YouTube run on Grumpy yet?
评论 #13320761 未加载
weberc2超过 8 年前
I tried a simple `http.Get()` example, but the resultant `Response` object appears to not allow access to any of the struct fields as attributes. How does one access a Go object&#x27;s fields from Python? For example, I want to `io.Copy(os.Stdout, rsp.Body)`.
评论 #13321714 未加载
nodivbyzero超过 8 年前
Facebook: PHP -&gt; HipHop<p>Google: Python -&gt; Go
kristianp超过 8 年前
Insightful discussion in the comments here about performance and JITs <a href="https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;710634&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;710634&#x2F;</a>
waitingkuo超过 8 年前
Will Grumpy be a good fit for go&#x27;s scientific packages such like gonum?
评论 #13320933 未加载
stiff超过 8 年前
It&#x27;s actually a transpiler written in Python that generates Go code.
评论 #13320725 未加载
statsmatscats超过 8 年前
Will you continue maintenance on this indefinitely (barring orders from higher up) or is this meant for a one shot translate and dump?
gigatexal超过 8 年前
on a related note: given my affection for python and having, until just now, no idea that YouTube runs python (albeit 2.7) at Google scale (a language not known for being able to scale very well given the GIL and such)-- I now more than ever would love to work on something like that. Welp, back to learning and hacking with python.
tiffanyh超过 8 年前
&gt;&gt; &quot;The front-end server that drives youtube.com and YouTube’s APIs is primarily written in Python, and it serves millions of requests per second! YouTube’s front-end runs on CPython 2.7, so we’ve put a ton of work into improving the runtime and adapting our application to work optimally within it.&quot;<p>So has YouTube already migrated over to using Grumpy (and no longer running python in production)?
Sir_Cmpwn超过 8 年前
God, will Python 2 just die already?
acd超过 8 年前
May I suggest GoPy as name
评论 #13322779 未加载
philip1209超过 8 年前
With click.py, this could make amazing command line utilities
jsmith_dev超过 8 年前
Win for crypto library inclusion <a href="https:&#x2F;&#x2F;twitter.com&#x2F;jsmith_dev&#x2F;status&#x2F;816894517844418561" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;jsmith_dev&#x2F;status&#x2F;816894517844418561</a>
sandGorgon超过 8 年前
any chance you guys have tested this with numba?<p>that would be awesome.
sheerun超过 8 年前
I&#x27;d love something like this for JavaScript
BuckRogers超过 8 年前
This is the best news to come out of the Python space in a very long time. Python on the Go runtime, no GIL, more performance, is exactly what people wanted out of a new Python.
codebungl超过 8 年前
+1 to cooperative multitasking
brian_herman超过 8 年前
No C extensions boo.
评论 #13320241 未加载
senthilnayagam超过 8 年前
wish there was one for ruby as well
MrBra超过 8 年前
Sometimes I really wonder what Google has against Ruby.
vegabook超过 8 年前
2.7 haha. First Tensorflow, now Grumpy. I can&#x27;t stop laughing as all the 3.x zealots try to squirm out of this. Talk about awkward.<p>yes yes I know tf now &quot;does&quot; 3 but we all know what Google really cares about.<p>&quot;I&#x27;d like to support 3.x <i>at some point</i>&quot; - trotterdylan.<p>Read: nice to have but when it gets down to brass tacks, 2.7 is where it&#x27;s at for Google.
Antwan超过 8 年前
&quot;So we asked ourselves a crazy question: What if we were to implement an alternative ?&quot;<p>As always with Google...<p>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 ?
评论 #13321642 未加载
评论 #13321456 未加载
BuckRogers超过 8 年前
Is this the final nail in the coffin for Python3? Seems like it.<p>Who would use 3 if you could have CPython2 for existing code and write new code in Grumpy Python? This is the dream language for me. Python on the Go runtime.
评论 #13321077 未加载
评论 #13322463 未加载