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

261–270 of 463 posts

Re: Grumpy: Go running Python

#261

Post by the_duke »

ericfrederich wrote: post #74
the_duke wrote: post #36

Earlier quoted context omitted.

Actually, I would interpret this as "CPython is broken for scalability. It's not worth trying to fork/fix it, we'd rather just roll our own runtime". 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.

I agree and disagree ... on one side this may signal a shift away from Python. Something to help the migration effort and the ultimate goal is to write everything in Go. ... but then I don't see Python going anywhere anytime soon. Didn't Microsoft just start a project to get Python's runtime to use CoreCLR's JIT? There was an article, can't find it now, about an upcoming Python renaissance saying there may be an infl…

Devs love Python and will continue to do so, no question there.

I'm just afraid the surge of different compilers and interpreters will bring up plenty of issues in the medium term.

There is no formal spec of Python like there is for, eg, Javascript. (which is of course driven by multiple, VERY engaged adopters).

How long until subtle and not so subtle differences creep in between different implementations, leading to incompatabilities and a continuous fragmentation of the ecosystem?

Re: Grumpy: Go running Python

#262

Post by fletom »

BuckRogers wrote: post #97

Is this the final nail in the coffin for Python3? Seems like it. 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.

Python 3 is a more modern, better language, that's why. Hopefully, grumpy will support it soon enough, though it's understandable that they started with 2.7 to support Google's huge older codebase.

Re: Grumpy: Go running Python

#263

Post by weberc2 »

Animats wrote: post #112
jerf wrote: post #46

For those who are interested, I've used grumpy to compile the following Python code and placed it at https://play.golang.org/p/YP1SP7WsdR . (Note the playground can't run this, it just had convenient formatting support for Go; the generated source wasn't 100% gofmt compliant.) class Test(object): def __init__(self, value): self.value = value def method(self): print(self.value) class Test2(Test): pass t = Test("hello"…

That's fascinating. It's creating run-time data structures similar to CPython's for data, and manipulating them with very general code. There seems to be a type comparable to Python's internal CObject, and it's used for most (all?) data. It's not generating Go that looks anything like human-written Go. There's no sign of type inference, although it's hard to tell from such a simple example. It's a lot like a Python r…

> Still, once you can do that, you can start optimizing, such as inferring that something is an integer and using ordinary Go arithmetic types.

I was hoping for something more aggressive even, like compiling Python classes to Go structs so long as the program doesn't need the dynamic behavior. Alternatively, Grumpy could support declaring native Go types via some sort of pragma or a new `struct` keyword or some such, which would be treated like a normal Go object (rather than defining your Go objects in a separate Go package).

Re: Grumpy: Go running Python

#264

Post by viraptor »

pjmlp wrote: post #114
sfifs wrote: post #27

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). It's interesting to see the same pain has now made caused the runtime itself to be implemented in Go. It's a pity C extensions (often used in scientific computing) are not supported but Go does have support via CGO, so maybe some…

I never saw Python as anything more than a scripting language to portably automate tasks across UNIX and Windows environment, even back in the Zope days. My experience with Tcl teached me to stay away from languages that don't have either a JIT or AOT compiler on their reference implementation.

AOT can be done by Cython and it's fully compatible with reference as far as I know.

Re: Grumpy: Go running Python

#266

Post by curtis »

dochtman wrote: post #182
curtis wrote: post #171

Earlier quoted context omitted.

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…

It seems likely to me that Rust is your better C++. I'm also quite positive that there is (more than) enough oxygen for Rust to succeed. As for D, I think it has numerous other issues, that don't apply to Rust.

The stuff I've done in C++ would have worked as well or better in a language with garbage collection. On the other hand if you want to write the next OS kernel, then you need a "better C++" that is designed to work without GC. In the latter case, I think there is no question that Rust is your best bet today. I'd like a programming language that is statically compiled, with good performance, garbage collection, and decent support for abstraction. It's the last part where I think Go comes up short, and I think the Go designers think that's a feature not a defect.

Re: Grumpy: Go running Python

#267

Post by weberc2 »

jerf wrote: post #14
Twirrim wrote: post #5

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?

Ask yourself how much Python code you think Google has. Then multiply it by some large single-digit number, minimum. Then compare the effort of spending 30 seconds per line on that code vs. writing a new Python interpreter/compiler/runtime, especially when you can trivially get people who are capable of doing that. There's a reason why the large companies often end up working on new runtimes/interpreters/compilers li…

It's interesting to think of the dynamics of developing an application (presumably) many times more complex than its host language. At a certain point, changing the language implementation becomes cheaper than making sweeping changes to the application.

Re: Grumpy: Go running Python

#268

Post by gsnedders »

LeifCarrotson wrote: post #180
coldtea wrote: post #156

Earlier quoted context omitted.

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.

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.

Re: Grumpy: Go running Python

#269

Post by mdaniel »

Animats wrote: post #132
TillE wrote: post #66

Earlier quoted context omitted.

> Nobody uses that stuff in production code Nobody uses the features of Python which make it a dynamic language? Google must write some really weird Python if their compiler is that strict.

In Python, you can get at a variable, or even code, in another thread with "getattr()". You can monkey-patch another thread while it is running. This is not very useful, but it's easy to implement in a naive interpreter such as CPython. Part of the price for this is the Global Interpreter Lock, so you don't really have two threads running at once. PyPy has a huge amount of machinery so that stuff will work. Grumpy do…

> That's a good thing. If you restrict Python a little, it's much easier to compile.

Isn't that more or less what RPython does? https://rpython.readthedocs.io/en/latest/architecture.html I mean, I know that starting with a full-fledged(?) Py27 codebase rules out _actually_ using RPython for the stated goals of Grumpy, but I think the two projects agree in principle and differ about the definition of "restricted" :-)

Post reply on HN