Live data from Hacker News

Grumpy: Go running Python

opensource.googleblog.com

251–260 of 463 posts

Re: Grumpy: Go running Python

#251
I can't help but see this balkanization of Python as a sign that the core language is falling apart.

How many interpreters are there now? And how many of them have even close to 100% compatibility with Python 2.7 or 3.N? Guido has lost control of the language, but has he's still officially the BDFL there'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's fundamental problems... it really feels like Python is lost in the desert.

Which doesn't mean the language is dead, but it's rudderless. I think we were all hopeful when Guido joined Google that we'd see real direction for Python, but that obviously didn't happen.

Not that Python is dead, obviously - still lots of great projects are written in Python. But I don't like the language's future.

Re: Grumpy: Go running Python

#252
post #251

I can't help but see this balkanization of Python as a sign that the core language is falling apart. How many interpreters are there now? And how many of them have even close to 100% compatibility with Python 2.7 or 3.N? Guido has lost control of the language, but has he's still officially the BDFL there's no real standardization body. His stubborn view on functional mechanisms have held the language back syntactical…

It's not that different from what's happening with Java (via Android) or Go (with GopherJS, for example), or even C (many, many extensions). A popular language attracts implementors, even if they don't implement the whole thing on their target platform.

Re: Grumpy: Go running Python

#253
post #251

I can't help but see this balkanization of Python as a sign that the core language is falling apart. How many interpreters are there now? And how many of them have even close to 100% compatibility with Python 2.7 or 3.N? Guido has lost control of the language, but has he's still officially the BDFL there's no real standardization body. His stubborn view on functional mechanisms have held the language back syntactical…

Why do you think multiple implementations are a problem? We've got multiple ruby runtimes, multiple basics, multiple JavaScript engines, multiple C compilers, etc. None of those languages are falling apart because of it.

Re: Grumpy: Go running Python

#254

Earlier quoted context omitted.

What's the advantage of writing an interpreter? Go already has an excellent runtime (scheduler, GC, etc)--why should this project reimplement it?

The interpreter could still use that stuff. One advantage of an interpreter in general is that one important use case for Python is interactive scripting, as data scientists do.

Fair point. I would think it shouldn't require too much work to build a REPL on top of this. Rather than transpiling, you would parse the Python AST into the same runtime Objects that Grumpy constructs statically. Seems straightforward conceptually, though I'm sure it would be complex in practice.

Re: Grumpy: Go running Python

#256
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…

Go and D both made the design choice to have garbage collection heavily intertwined with the language (or at least the standard library), which makes them not really suitable for replacing C++ in most applications. Rust doesn't have a GC, so it should do better in that niche. It's always seemed like Google wrote Go to for the purpose of having a "faster Python"--where they were writing components in Python that weren…

I'm not certain that the goal was a substitute for Python, but either way I think you can make the case that it's worked out that way. It seems like a lot of people who ended up moving to Go started out with Python or maybe Ruby rather than one of the statically typed languages.

Re: Grumpy: Go running Python

#257
post #251

I can't help but see this balkanization of Python as a sign that the core language is falling apart. How many interpreters are there now? And how many of them have even close to 100% compatibility with Python 2.7 or 3.N? Guido has lost control of the language, but has he's still officially the BDFL there's no real standardization body. His stubborn view on functional mechanisms have held the language back syntactical…

GVR, the PSF and the core dev team overestimated their influence. They still truly believe the majority will come around to Python3. I agree with your sentiments and balkanization is the right word. Guido won't even read these comments. He thinks it's all some unjust slander and nonsense that will be forgotten in 3 years. :)

It is a good time to jump off the Python train in general, and I say that as someone invested in Python who loves it. If possible I'd recommend people reach for Go or Elixir depending on their needs or requirements.

I will admit I'm a little shocked how much of a failure Python3 adoption has been. I think if it had been Grumpy from the start it would've been a huge success. This is exactly what people want and Google should be commended for sharing this.

Here's to hoping Grumpy takes on a life of its own and is the new de facto Python.

Re: Grumpy: Go running Python

#258
post #215

Earlier quoted context omitted.

Just because the site is popular doesn't mean the codebase is big. It's a simple site. I could probably write YouTube in Go in an afternoon and I don't even know Go.

This comment made me wonder what you consider to be a complex site.

Not a video host with comments. That's practically CRUD. A very solved problem.

Re: Grumpy: Go running Python

#259
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"…

Interesting to note that `print()` is supported out of the box--no need to `from __future__ import print_function`.

Re: Grumpy: Go running Python

#260
post #113

Earlier quoted context omitted.

Please watch that first video, it's a good one. It explains how CPython essentially _is_ the spec because its internals leak into the spec when they have no business being there.

Pretty much the same is true about most other languages that have a single main implementation. This is even true, to some degree, for Java, which had competing implementations relatively early on.

At some point it leaked pretty hard as well. The package scope was an unspecced implementation behaviour that became a standard later. (If I recall the story correctly)
Post reply on HN