Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyston v2: Faster Python

blog.pyston.org

Post reply on HN
Print view View original

171–180 of 211 posts

Re: Pyston v2: Faster Python

#171

Post by dnr »

saurik wrote: post #38
throwaway894345 wrote: post #29

Earlier quoted context omitted.

This is why I see little hope for Python, which is to say that while I'm sure it will continue to have a large following for many years a la C, C++, etc, I don't have hope for it being an exciting language or one that is particularly productive. Python already has performance and packaging problems which don't seem to be easily divorced from CPython, since virtually the whole reference implementation is depended upon…

100% agree. To a very real extent, Go probably only exists at all because Google poured an infinite amount of effort into Unladen Swallow--a project designed to remove the GIL from Python 2 to make it more usable for concurrent programs and add an LLVM-based JIT compiler to improve performance--and Python's response was to not only not merge it, but to break the entire Python ecosystem for a decade by forking the lan…

As other people have pointed out, almost none of this comment is accurate:

Google put some effort, not that much, into Unladen Swallow, and the people who worked on it admitted that it didn't achieve the goals they set. The Python community was well on their way to creating Python 3 before work started on Unladen Swallow (so it was not in any way "Python's response"). As other comments pointed out, Google did not hire Rob Pike to "do" Go. Go was initially a side project of a few people and had nothing whatsoever to do with Python. The Go team was surprised when Python users started migrating to it. Google never used Python for web development, with one major exception, Youtube, an acquisition. I also don't understand how Google has "moved on" from Python (this seems unlikely) and how what they use Python for internally has anything at all to do with the fate of Django and Python webdev.

I don't mean to pile on, but I kinda have to ask, what were you thinking when you wrote this comment? Do you believe all those statements, or were you taking huge liberties with facts and making guesses to tell a story that supports a statement you wanted to make? You seem like a valued member of the community and this kinda makes me distrust the accuracy of everything else you write. (And to be honest, makes me distrust more of what I read in general, which is probably good but sad.)

A couple references for history/dates:

https://en.wikipedia.org/wiki/CPython#Unladen_Swallow https://www.python.org/dev/peps/pep-3000/

Re: Pyston v2: Faster Python

#172

Post by semi-extrinsic »

xvilka wrote: post #160
solidasparagus wrote: post #143

Earlier quoted context omitted.

Go and Python have pretty minimal overlap IMO. If you are using Python for anything other than a server or CLI, Golang is not a very good replacement for Python. Some of Python's strengths that I work with regularly are dynamism, easy data exploration, visualizations, succinct & customizable syntax, extremely strong data science libraries, REPL/Jupyter, C bindings, easy to use packaging solution via PyPi (bet some pe…

Julia covers your use cases and overwhelmingly fast.

My gripe with Julia etc. as replacements, is that Python is duct tape. I don't need fast duct tape, I need duct tape that is understood and used by essentially everyone I work with, and that has native, fast handling of large amounts of data (NumPy, Pandas). Good user experience as duct tape.

From my perspective Julia is sacrifising some amount of "duct tape UX" to gain speed, and that's the wrong direction.

Whenever we need more speed, we just pull the slow bits down into compiled languages, and scale them out to many cores with solutions like MPI.

R is another language that is mainly duct tape for stringing pieces of compiled code together. If it had a better UX for developers than Python, I think we would see it dominating much more today, without having any speed advantage.

Re: Pyston v2: Faster Python

#174

Post by bastawhiz »

theamk wrote: post #127

Wanted to see redistribution rules, and was surprised to see there is no license anywhere for the binaries... The closest thing I found is "copyright" file inside .deb: Copyright: 2020 The Pyston Team License: Closed source, all rights reserved. I guess it means no one should be touching the file, as they haven't even granted access to run it.

From the link:

> Our plan is to open-source the code in the future, but since compiler projects are expensive and we no longer have benevolent corporate sponsorship, it is currently closed-source while we iron out our business model.

Re: Pyston v2: Faster Python

#175

Post by adrianN »

mhh__ wrote: post #107
chrisseaton wrote: post #21

Earlier quoted context omitted.

> I don't use Python for speed, but for ease-of-use. Right - but if you can get that with better performance that's good isn't it? I don't get why people object to performance work on languages not intended for performance.

> I don't get why people object to performance work on languages not intended for performance My gut feeling is that Python is just not safe or static enough to ever be worth trying to compete with (say) C++ with. Python sure is easy but I think the asymptotic cost of using it for a big project (in my hands at least) is just not worth it. I like Python's syntax quite a bit but I feel bad watching people learn to prog…

You don't have to compete with C++. If switching the interpreter allows you to save 20% server costs at ~0 development cost that's a no-brainer. Rewriting your stuff in C++ might allow you to save 95% of your server costs, but development cost is a lot higher.

Re: Pyston v2: Faster Python

#176

Post by pjmlp »

throwaway894345 wrote: post #163
mrtranscendence wrote: post #88

Earlier quoted context omitted.

I'll be honest, as someone whose non-Python programming (paltry as it is) is mostly done in statically-typed functional languages, I have a bit of a bias against Go for the whole generics thing. I'll give it a closer look at some point.

I understand; lots of people have this sentiment. It’s an inconvenience in many cases, but we’re comparing it against Python, which has no type safety at all much less generics (apart from Mypy, which has many, many other issues).

All dynamic languages are generic by default.

Re: Pyston v2: Faster Python

#177

Post by pjmlp »

uranusjr wrote: post #46
saurik wrote: post #38

Earlier quoted context omitted.

100% agree. To a very real extent, Go probably only exists at all because Google poured an infinite amount of effort into Unladen Swallow--a project designed to remove the GIL from Python 2 to make it more usable for concurrent programs and add an LLVM-based JIT compiler to improve performance--and Python's response was to not only not merge it, but to break the entire Python ecosystem for a decade by forking the lan…

Didn’t the original Go creators mention on multiple occasions they intended to build a replacement to C, only accidentally produced an application language? Assuming that’s true, Go would have happened regardless. Google couldn’t have pulled out of Unladen Swallow before Go is usable, since they could not have known it’s actually an alternative at the time.

C++ actually, but most of us did not care.

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

If this version of generics finally makes it, then I care, otherwise only when dealing with Docker and Kubernetes eco-system.

Re: Pyston v2: Faster Python

#178

Post by kzrdude »

There has been many faster python threads lately, I'm looking forward to improvements, especially, those that reach CPython!

As others have been pouring out before, the new load attr opcache is maybe the most interesting recent performance improvement that was merged.

Re: Pyston v2: Faster Python

#179

Post by globular-toast »

theamk wrote: post #127

Wanted to see redistribution rules, and was surprised to see there is no license anywhere for the binaries... The closest thing I found is "copyright" file inside .deb: Copyright: 2020 The Pyston Team License: Closed source, all rights reserved. I guess it means no one should be touching the file, as they haven't even granted access to run it.

> I guess it means no one should be touching the file, as they haven't even granted access to run it.

Since when does someone need to explicitly grant you permission to run a program on your own computer?

Re: Pyston v2: Faster Python

#180

Post by fnord123 »

fnord123 wrote: post #110
rhencke wrote: post #54

Earlier quoted context omitted.

Google did not hire Rob Pike with Go in mind. Go did not even come around as an idea until Pike had worked at Google for a while. [1] Don't forget Rob Pike created Sawzall at Google first (2005). [2] [1] https://golang.org/doc/faq#history [2] https://research.google/pubs/pub61/

The early Go compiler reused the code generator from Limbo. To the point that many comments referred to Limbo. So while Rob Pike might not have joined Google to work on Go or had Go in mind, the idea and direction for Go was probably preordained. It doesn't really support or attack your claims. It's just a thing I wanted to share.

Small mistake: there are references to inferno, the operating system which limbo was a key component in. The broad idea is the same: Go has a clear heritage in systems that Rob Pike already worked on.
Post reply on HN