Slashdot Mirror
Google Boosts Python By Turning It Into Go (infoworld.com)
An anonymous reader quotes InfoWorld:
Grumpy, an experimental project from Google, transpiles Python code into Go, allowing Python programs to be compiled and run as static binaries using the Go toolchain... In a blog post announcing the open source release, Google stated the project stemmed from its efforts to speed up the Python-powered front end for YouTube. But Google hit an obstacle that's familiar to folks who've deployed Python in production: It's hard to get CPython -- the default Python interpreter written in C -- to scale efficiently. "We think Grumpy has the potential to scale more gracefully than CPython for many real world workloads," writes Google...
Because it doesn't support C extensions, Grumpy doesn't have CPython's Global Interpreter Lock, which is commonly cited as a roadblock to running Python concurrent workloads smoothly. Grumpy also uses Go's garbage collection mechanisms to manage memory under the hood, instead of CPython's. Grumpy creates close interoperation between Python and Go by allowing Go packages to be imported and used with the same syntax as Go modules.
Because it doesn't support C extensions, Grumpy doesn't have CPython's Global Interpreter Lock, which is commonly cited as a roadblock to running Python concurrent workloads smoothly. Grumpy also uses Go's garbage collection mechanisms to manage memory under the hood, instead of CPython's. Grumpy creates close interoperation between Python and Go by allowing Go packages to be imported and used with the same syntax as Go modules.
Is Mozilla doing something similar, but using Rust instead of Go?
Just rewrite the code to Go. Or, even better, don't use Go because Go is a trash fad language that'll be dead in five years.
A Python eating its tail and forming a wheel, making it Go easier.
Anybody compiled youtube-dl yet? It's bloated as shit and too fucking slow to use as a web service for streaming on demand.
What are they talking about? Stop inventing new shit all the fucking time, and just fucking stick to what fucking works and is stable. You never let anything settle. You constantly crave change for the sake of change. Fuck off. Slow the fuck down. My Windows 10 hasn't even updated to Anniversary Edition yet, and there are already multiple major updates since. It's insanity. Stop changing everything. Go back to the UI of Windows 95 and start over from there. Stop making new programming languages. Stop doing all this stupid shit.
Four post and no mention of religion, trump, racism, or apers aping apes. Am I in the wrong place.
You be the judge.
My pithone
UNITE with the Campaign for a Free Internet because today, our future begins with tomorrow!
1. parse python into AST.
2. reformat with curly braces.
3. take over the world; there would be no stopping a curly-braces version of python.
Python's GIL. Pythonistas keeping pushing for Python everywhere but don't realize that Python does have its limits and is not the language of choice if you need performance on multiple cores. In my experience, when you try to emulate multithreading in Python using some message passing scheme you end up with something that is more complicated, harder to debug and tune, harder to maintain, than the equivalent written in good C++.
Google didn't invent Python. That was developed by Guido R. at another organization. Years later, Guiodo went to work for Google, well after Python's ascendant popularity.
Android was also developed by another company that Google later bought. Same thing with Youtube. Do you see a pattern yet?
So it can only support pure Python code? That pretty much rules it out for many applications where speed is an issue, where C extensions are common (and not just for performance reasons). In which case, might as well use PyPy: all the advantages of Python, the JIT can give native performance, and you can use all the existing high performance libraries written in C (or Fortran!). Sure, I grant you that Grumpy does have the advantage of making a self-contained executable, but there are ways to do that with PyPy.
Is this going to go the way of Google's Unladen Swallow fork of CPython?
oH whoops, cant use a facebook framework/jsx.
hahaha
why cant google use its own technologies, such as Polymer/webcomponents
But youtube interface sucks , thumbnails have no tooltips, dont show time stamps. When a paused video in full screen goes to window mode, it starts play back again. Also they show ads that are longer than the videos sometimes, (39min ad for 4min video)
Where is the SBS mode 3D interface for 3dTVs ? I can play back SBS 3d videos, but the interface web page it self is not in 3d mode, or even viewable in 3d mode.
Liberty freedom are no1, not dicks in suits.
Well COBOL has both funky syntax rules and scalability. Nearly there guys!
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
It should use the Java JIT compiler to run much faster than any byte code interpreter.
That said, I do not know why anybody would even think of using a programming language without static typing. Not for performance, but rather for sanity when writing and (more importantly) maintaining code. With type inference it costs virtually no extra typing.
I am so tired of people complaining about GIL. They all seem to miss something really, really, really fundamental. Threads are not useful in multicore environment for anything other than scheduling IO blocking. There is a reason why UNIX was so process-centered in its multitasking while Windows was thread-centered. UNIX was designed to run on multi-core (albeit often slow cores) machines. Windows was designed to multitask on single-core machines. On single core machines using threads to schedule CPU-bound threads makes sense. On multi-core machines it doesn't. Since there are multiple CPU contexts, there is no context switch to get around. IPCs should be just as fast as cross-thread data travell (because neither requires a context switch -- the biggest slow down). And now all the languages (even C++) are trying to implement something which should really be in the domain of the operating systems (CPU-bound thread scheduling). So all the languages all of a sudden need a huge "runtime" (which really becomes a micro-kernel if it's doing the job that the kernel should be doing). Stop. Let OS's compete on who does resource management better across multiple cores. It's not a job for any user-space language.
There have already been several excellent implementations of Python that compile to native code, either via JIT or directly, including IronPython. But Python's performance problems aren't in Python code, since anything compute intensive is done in native libraries. The real problem with all of those implementations is that, like Grumpy, they don't have native, thread-safe libraries, foremost Numpy and Scipy.
Grumpy sounds like an attempt to migrate Python users to Go. That's probably the right idea, because Python seems to be going nowhere fast. Go, however, is probably not the right language to migrate to, despite its moderate adoption in some systems applications, mostly because Go just gives the finger to existing programming practice for no other reason than FYTW.
Can we fucking STOP using this abomination? A compiler ALREADY translates between two languages!!!!!! what the fuck is new about "transpiling" STOP IT RETARDS
Nitpicking, buy it was JPython in 1997
It has been Jython since 1999
https://wiki.python.org/jython...
> I do not know why anybody would even think of using a programming language without static typing.
- Dynamically typed programming languages are more productive when writing smaller quantities of rapidly evolving code.
- It is mainly a library and an ecosystem issue. Python tends to have all the modules I need, while Haskell, OCaml and Scala often don't... and they often seem to be much easier to pick up and use.
For example, Pandas equivalents are much less mature in other ecosystems. On language merits alone, I should be using Scala more than Python, but in practice, Python modules win me over.
I wanted to memoise a function. To look up a module and put in the couple of lines (an import and a decorator) needed to achieve that probably took a couple of minutes in Python, and I was back to the real meat of my code. I would have spent much longer in Java.
I like that these languages all bring new ideas and are a great learning opportunity; erlang and go have interesting programming models and CSP/actor functionality. But I feel I should be able to enjoy these things in other languages after they have a while to get absorbed, that's not generally the case though, for example I've been reading about using akka in java for a while now and the syntax looks clumsy to my eye compared with erlang and I've totally failed to get my head around scala.
same thing with improvements in the build/deploy chain. If transpiling to golang is significantly better then I'll take that win, and simply use go as a stepping stone to deploy the python syntax that I like.
I'm fumbling to say that I think that once several years have passed and a new programming idea has become accepted and proven its worth, them most of the major language syntaxes should grow support for it. There should be a simple CSP syntax for Python, it should be possible to compile erlang for the JVM, to reasonably implement actors in java etc..
Then I won't have to endure so many eye rolls when I suggest erlang for that highly concurrent system to the diehard python or java devs or to the managers that want nothing to do with anything too shiney
Nullius in verba
Both 2.7 and 3.6 documentation clearly state that you can't have multiple statements in a lambda function definition:
https://docs.python.org/2/refe...
https://docs.python.org/3/refe...
In fact the function body part of the lambda is not a statement at all, but a single expression that becomes the function's return value:
https://docs.python.org/3/refe...
Re Python:
I would settle for the ability to extend the built-in classes, str in particular. My "settle" went like this:
1) Inquired politely about same
2) Python nerds have orgasm telling me why this is terrible. I am, to put it mildly, dubious.
3) I write 100% compatible pre-processor that gives me the syntax I wanted.
4) PROFIT. Okay, well, not really, but EXTENDED STRING CLASS METHOD SYNTAX!
Like...
myString = 'foo'
otherString = myString.doHorribleThing('bar')
print 'good'.grief()
So...
You could do the same. What you want, perhaps, might be much easier than what I did. In fact, you could fork my project and add what you want to it. I'm already parsing the language reasonably well, which is arguably one of the difficult parts.
You don't always have to wait for a language's maintainers to get off their butts to address shortcomings or instantiate new goodies. Or eventually not do anything at all. There are other paths to nerdvana.
I've fallen off your lawn, and I can't get up.
Instead of translating to Go, why not directly translate to C, or even to language machine?
How is this different from what Cython has been doing for years? There's nothing new about the idea of translating Python to a statically compiled language to improve performance.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."