Grumpy: Go running Python!
29 comments · 95% upvoted · source · other discussions
comments
[deleted]
garoththorp
Oh man I can't wait for the inevitable future:
- Oh hey, there's a sweet python library
- But humm, I wrote my project in Node :-(
- Oh, no problem: get GopherJS and just transpile python -> Go -> Javascript
drunken_thor
Isn't that kind of awesome though? Imagine a future where you can write any language and change at any point. Maybe you are running into limitations of one language so you translate to another without any repercussions? Or as you said translating libraries. Write libraries that work for any language. A bit far fetched but cool to think about.
khrizp
Have you heard about Haxe? https://haxe.org/ I think Haxe can be use for something like that.
aaaqqq
I'm excited to see if this can result in making a large number of very useful & battle tested python packages available for use in Go. That would be pretty awesome!
saxykeyz
wonder how easy it would be to use grumpy as a library in other go programs
ctbel
I'd like to know that as well. Perhaps this could be a start?
https://godoc.org/github.com/google/grumpy/runtime#Code.Eval
[deleted]
[deleted]
m3wm3wm3wm
Is this a tool mainly for migrating a legacy Python codebase, or, is it suitable for new projects?
Would new web app projects benefit from writing in Python and transpiling to Go?
neoasterisk
New web projects are probably being written in Go.
dAnjou
So, the reason was that Python 2 is bad at concurrency. But how does a transpiler help solving this issue? I don't think you can simply "translate" normal Python code to code that runs concurrently automagically ... whatever that means. All that is a way too big question mark for me to get excited about this project just yet.
prite
Python has concurrency models — even python 2.7 — what it (read: cpython) doesn't have is parallelism.
There are already implementations that bring parallelism to python's concurrency, in fact. This one just tries to do it in Go.
ehaliewicz
The main issue is that cpython is reference counted, which can cause problems with threads, unless you're very careful with the refcounting logic. Most of python should run fine with a GC (pypy uses one after all), and that could allow much better parallelism, although python also supports destructors which don't necessarily play well with GC.
[deleted]
[deleted]
ehaliewicz
there is no runtime GC. It's all just Go at that point with the standard go runtime/GC.
I wouldn't really expect there to be a gc running on top of the go gc..
weberc2
There isn't--it uses Go's GC.
ehaliewicz
I understand that. The other was saying there's no runtime GC because go has it's own GC???
All I was saying from the beginning is that it's using go's GC rather than reference counting so that'll help with parallelism.
amclennon
So, the reason was that Python 2 is bad at concurrency. But how does a transpiler help solving this issue?
I'm not sure how familiar you are with Python, but any application that has multiple threads will still be bound to a mutex called the Global Interpreter Lock (GIL) for any CPU related tasks. In other words, only one thread can make heavy use of the CPU at any given time despite other potential gains from threading.
In general, the default CPython platform is going to be inherently slower at interpreting the code at runtime. I imagine you'd also get a lot of the benefits from a Golang build that you'd get with something like PyPy by performing static analysis and generating a binary ahead of time.
[deleted]
dAnjou 15 points · Jan 2017
So, they do convert the Python code. They just do it automatically rather than manually. I guess the options were to let an army of developers rewrite everything from scratch or to let a handful of smart people write a new "runtime" (whatever that implies).
xiegeo 6 points · Jan 2017
I think there are two different types of transcomplers. One is like a traditional compiler in that the output is only meant to be machine readable, and code should still be written in the original language, with binding to the target language to take advantage of its features. The other is what you described, a machine aided conversion to a new language. My understanding of the article is that it is the first case.
weberc2 6 points · Jan 2017
It is. Grumpy programs are pretty much entirely
grumpy.runtime.Objects, very much like the PyObject in CPython from what I can tell. In other words, classes don't compile into static Go structs, but into a runtime Type instance.dAnjou 1 points · Jan 2017
Nope, I just used OP's wording when I said "convert". I'm not aware of any transpilers who's primary purpose is to produce human readable code. AFAIK TypeScript manages to do that. But still, what'd be the point of working with this output?
xiegeo 2 points · Jan 2017
I see. The second is what you want to do for a rewrite such as converting the Go compiler from C to Go. https://talks.golang.org/2014/c2go.slide
[deleted] 0 points · Jan 2017
[deleted]
TheMerovius 1 points · Jan 2017
No. Anything I'd call a "pretty printer" has the same input and output language. gofmt is a pretty printer. The C->go transpiler used when migrating gc and the runtime to go isn't, it's a transpiler.
[deleted] 7 points · Jan 2017
Reminds me of facebook and the hhvm/hack