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

191–200 of 463 posts

Re: Grumpy: Go running Python

#191

Post by goatlover »

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.

The scientific community thinks otherwise.

Re: Grumpy: Go running Python

#192

Post by goatlover »

pjmlp wrote: post #181
jszymborski wrote: post #139

Earlier quoted context omitted.

I think that that's rather dismissive of a language that runs huge web, scientific, and general purpose applications daily.

It might be, but that it is usually a consequence of not knowing any better or making use of existing libraries. Just like people learned 8-bit BASIC and went on to do business applications and games on it. I went Z80 ASM instead. Personally I would only use Python for shell scripting and advise for using Julia instead. Of course, others see it differently.

Julia's nice, but it's playing catch up to R & Python. Name any statistical algorithm, and R probably has it. Name any scientific field, and there's probably a Python library for it.

Re: Grumpy: Go running Python

#193

Post by tedmielczarek »

poooogles wrote: post #59
Animats wrote: post #48

- Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. - It's a hard-code compiler, not an interpreter written in Go. That implies some restrictions, but the documentation doesn't say much about what they are. PyPy jumps through hoops to make all of Python's self modification at run-time features work, complicating PyPy enormously. Nobody uses that stuff in production code,…

>- Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. Python 2.7 is what's running at Google. Not really surprising they're looking at this considering the fast approaching end of (core dev) support for Python 2.7. Write an interpreter in another language and programatically port modules to Go. Seems pretty sensible to me.

Given the failure of their unladen-swallow work to make it into CPython, I think Google is probably tired of trying to make Python faster. Some of their stated goals with Go were to be a faster, compiled Python, so this makes a lot of sense for their use case. They face the choice of fixing all their existing Python code to run in Python 3 (which won't make anything faster), or just porting everything to a different language. They chose the latter, and this lets them incrementally convert Python code to Go. I don't know that this makes sense for anyone but Google, just like Hack probably doesn't make sense for most PHP development that's not at Facebook.

Re: Grumpy: Go running Python

#194

Post by tedmielczarek »

the_duke wrote: post #31
oblio wrote: post #6

It seems interesting but my concern is that it's just another Unladen Swallow.

Well, if Google is pushing it and actually using it internally... They also have the benefit of being able to push features into the Go core that they might need for this.

Google has pretty specific needs, so this project may be very successful internally even if it gets zero traction externally.

A lot of big software companies do this nowadays. Google and Facebook both have a lot of purpose-built software, some of which gets released as open source, that meets their needs well but is hard to use for other purposes. I guess it's still strictly better than them not open-sourcing the code, but it's definitely an existence proof that just making something open source doesn't make magic happen.

Re: Grumpy: Go running Python

#195

Post by jerf »

goatlover wrote: post #191
pjmlp wrote: post #114

Earlier quoted context omitted.

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.

The scientific community thinks otherwise.

The scientific community uses it as a tool to automate specification of tasks to be performed inside of C libraries. It's a case pjmlp may not have explicitly named, but it's of the same kind.

Re: Grumpy: Go running Python

#196

Post by lima »

shanemhansen wrote: post #145
quotemstr wrote: post #91

Earlier quoted context omitted.

> Python 2.7 is what's running at Google. Not really surprising they're looking at this considering the fast approaching end of (core dev) support for Python 2.7. I'd prefer that all new Python tools that need to support 2.x also support 3.x. It's an additional development cost, but IMHO, a worthwhile investment in the future.

While python2 may be the past, I think that for many python3 is not the future.

Highly depends on the use case.

Python 3.5 with uvloop+sanic can be faster than node.js without any JIT:

https://github.com/channelcat/sanic#benchmarks

Re: Grumpy: Go running Python

#197

Post by tedmielczarek »

curtis wrote: post #171
coldtea wrote: post #134

Earlier quoted context omitted.

> 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. It was designed with the notion that all some people really need is just a better C. For other people there's Swift, Rust, etc.

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't fast enough, they could write them in Go instead of having to resort to C++.

Re: Grumpy: Go running Python

#198

Post by jerf »

throwaway9912 wrote: post #164
jerf wrote: post #14

Earlier quoted context omitted.

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…

I don't know PHP, but in the case of Python you will spend the next ten years ironing out subtle incompatibilities between CPython and this new thing. Added up, it is easily more than 30s per line.

"Added up, it is easily more than 30s per line."

30s per line of current Python code, not compiler code.

And I'm just providing a number to put some numbers out there. 30s/line to convert a Python program to something fundamentally different like Go is probably an underestimate, yes, but then, if it's an underestimate that means the budget for the Python reimplementation is that much larger.

It also really helps the "subtle issues" when you control both the implementation and the code running on it; it means for every subtle issue discovered you have the option of either fixing the implementation or fixing the original code not to tickle the corner case. It's much harder when you only control one side or the other. It's not Google that will be having massive problems with corner cases.

Re: Grumpy: Go running Python

#199

Post by wolf550e »

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…

Are Go's integers unbounded? If not, proving the value never exceeds the range to silent convert essentially a BigInteger into an int might be hard.

Re: Grumpy: Go running Python

#200

Post by lima »

BuckRogers wrote: post #133
cdelsolar wrote: post #110

Earlier quoted context omitted.

That is pretty ridiculous. Pretty much all major libraries are Python 3 compatible and everyone is writing Python 3 (or should be). (Yes, I'm still on Python 2 but moving soon).

That's top-down change from the PSF/core dev team and some major library developers added dual 2/3 support. The users never arrived and it'll be 10 years Python3 has been available next December. I'd like to unify Python again but we as users didn't break it either. 10 years any reasonable person in charge would hang it up or change course. Grumpy is pretty much what most everyone would actually want out of a new Pyt…

> some major library developers added dual 2/3 support

> The users never arrived

That's the way it used to be a few years ago - it changed a lot the last few years. Pretty much all libraries are ported and many new libraries are Python 3-only.

asyncio is nice.

All Python devs I personally know moved to Python 3. Porting is a lot less painful than it used to be.

Post reply on HN