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

GraalPy – A high-performance embeddable Python 3 runtime for Java

graalvm.org

Post reply on HN
Print view View original

141–150 of 151 posts

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#141

Post by pjmlp »

BiteCode_dev wrote: post #44
yosefk wrote: post #34

Earlier quoted context omitted.

The reasons for all this stuff having been developed in Python also make Python interesting right now, all by themselves. It did not happen by accident; this stuff was developed fairly recently and there was no shortage of mature languages to choose from.

The people disliking the language are very vocal about it, but there is a huge amount of silent people that loves it and an even bigger amount that just like it as much as alternatives. It's mainstream now, not trending like 10 years ago, so there is no hype about it anymore. We just use it to do stuff. Add to that the existing excellent ecosystem, the strong culture of scientific stacks and a very good story for pro…

My only big critism is the CPython folks resistance to any kind of performance improvements, and the way PyPy efforts have been largely ignored, making Python the last major dynamic language to finally start caring about performance and having a JIT in the box.

Finally thanks to data science, and people getting fed up with always writing bindings, this is changing, and Python can join Common Lisp, Scheme, Smalltalk, SELF, JavaScript, Ruby, Lua, Dylan, Julia, BASIC club.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#142

Post by pjmlp »

wenc wrote: post #54
yosefk wrote: post #34

Earlier quoted context omitted.

The reasons for all this stuff having been developed in Python also make Python interesting right now, all by themselves. It did not happen by accident; this stuff was developed fairly recently and there was no shortage of mature languages to choose from.

As a former Perl hacker who started using Python in 2005, I saw Python ride several waves. (Numerical computation, data science, deep learning) Perl was the leading tool for scripting and text parsing. Python didn’t really supplant it for a long time — until people started writing more complicated scripts that had to be maintained. Perl reads like line noise after 6 months whereas I can look at Python code from 20 ye…

As someone that did the Perl to Python transition back in 2003, for UNIX scripting tasks, the way to do OOP with packages and blessed references was clunky, and having to always go back to the manuals for some clever programming tricks from team mates was tiresome, while Python provided something nicer, and I wasn't really into the sed/awk like features in Perl anyway.

However due to being a interpreted scripting language I never bothered to use Python for anything beyond OS scripting.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#143

Post by gpderetta »

BiteCode_dev wrote: post #44
yosefk wrote: post #34

Earlier quoted context omitted.

The reasons for all this stuff having been developed in Python also make Python interesting right now, all by themselves. It did not happen by accident; this stuff was developed fairly recently and there was no shortage of mature languages to choose from.

The people disliking the language are very vocal about it, but there is a huge amount of silent people that loves it and an even bigger amount that just like it as much as alternatives. It's mainstream now, not trending like 10 years ago, so there is no hype about it anymore. We just use it to do stuff. Add to that the existing excellent ecosystem, the strong culture of scientific stacks and a very good story for pro…

The people disliking the language might also be the people that love it. I know I am in that camp.

It is a great language in many ways, that's why its shortcomings are so painful.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#144

Post by gpderetta »

pjmlp wrote: post #141
BiteCode_dev wrote: post #44

Earlier quoted context omitted.

The people disliking the language are very vocal about it, but there is a huge amount of silent people that loves it and an even bigger amount that just like it as much as alternatives. It's mainstream now, not trending like 10 years ago, so there is no hype about it anymore. We just use it to do stuff. Add to that the existing excellent ecosystem, the strong culture of scientific stacks and a very good story for pro…

My only big critism is the CPython folks resistance to any kind of performance improvements, and the way PyPy efforts have been largely ignored, making Python the last major dynamic language to finally start caring about performance and having a JIT in the box. Finally thanks to data science, and people getting fed up with always writing bindings, this is changing, and Python can join Common Lisp, Scheme, Smalltalk,…

and elisp. Let's not forget that elisp got a JIT (well, actually a static compiler) before CPython did!

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#145

Post by neonsunset »

pjmlp wrote: post #141
BiteCode_dev wrote: post #44

Earlier quoted context omitted.

The people disliking the language are very vocal about it, but there is a huge amount of silent people that loves it and an even bigger amount that just like it as much as alternatives. It's mainstream now, not trending like 10 years ago, so there is no hype about it anymore. We just use it to do stuff. Add to that the existing excellent ecosystem, the strong culture of scientific stacks and a very good story for pro…

My only big critism is the CPython folks resistance to any kind of performance improvements, and the way PyPy efforts have been largely ignored, making Python the last major dynamic language to finally start caring about performance and having a JIT in the box. Finally thanks to data science, and people getting fed up with always writing bindings, this is changing, and Python can join Common Lisp, Scheme, Smalltalk,…

To be fair, Ruby YJIT can still somehow be slower than Python 3.11+ at times. Lua JIT is a bit of a separate effort and the ones that truly try the hardest here are Julia (which is not necessarily interpreted, it's really difficult to call it a pure scripting language at this point) and JavaScript engine implementations. I can see pretty good numbers for SBCL on BenchmarksGame too.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#146

Post by pjmlp »

neonsunset wrote: post #145
pjmlp wrote: post #141

Earlier quoted context omitted.

My only big critism is the CPython folks resistance to any kind of performance improvements, and the way PyPy efforts have been largely ignored, making Python the last major dynamic language to finally start caring about performance and having a JIT in the box. Finally thanks to data science, and people getting fed up with always writing bindings, this is changing, and Python can join Common Lisp, Scheme, Smalltalk,…

To be fair, Ruby YJIT can still somehow be slower than Python 3.11+ at times. Lua JIT is a bit of a separate effort and the ones that truly try the hardest here are Julia (which is not necessarily interpreted, it's really difficult to call it a pure scripting language at this point) and JavaScript engine implementations. I can see pretty good numbers for SBCL on BenchmarksGame too.

Yes, but it isn't the only one, the oldest Ruby JIT goes back to Ruby Motion, still being sold.

I would not put Julia and Common Lisp on the scripting basket yep.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#147

Post by pjmlp »

gpderetta wrote: post #144
pjmlp wrote: post #141

Earlier quoted context omitted.

My only big critism is the CPython folks resistance to any kind of performance improvements, and the way PyPy efforts have been largely ignored, making Python the last major dynamic language to finally start caring about performance and having a JIT in the box. Finally thanks to data science, and people getting fed up with always writing bindings, this is changing, and Python can join Common Lisp, Scheme, Smalltalk,…

and elisp. Let's not forget that elisp got a JIT (well, actually a static compiler) before CPython did!

Indeed, I only listed the languages I know more about, it has been a long time since XEmacs was my poor man's IDE on UNIX systems.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#148

Post by mike_hearn »

mk89 wrote: post #131
pantulis wrote: post #130

GraalVM is fascinating. Honest question: what are Oracle's plan for it? How does it serve them?

There is already an EE for it, so I guess they provide basic functionalities for free, and if you need additional features you have to pay?

EE is mostly free to use actually (check the licensing FAQ for exactly when). Graal features get integrated into Oracle products and make them better.

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#149

Post by malux85 »

upghost wrote: post #95
malux85 wrote: post #79

Earlier quoted context omitted.

This is pretty interesting, what's the benefit over using python so directly with java? I mean, is the overhead of having these as seperate services / processes too much? I'm not trying to provoke I'm genuinely curious about the use case. Also, what's the dev workflow like? When I'm coding python I basically live inside the debugger (a.k.a the carmark method), do you use an IDE that understands both java and python?…

That's a really interesting line of questioning! We have a mode called "embedded mode" where you run the python application first, THEN initialize the JVM and Clojure via the Python "javabridge" package. From there, you can start your Clojure REPL and experience both Clojure's IDE integrated REPL experience or the Python debugger, depending on how you set it up. This also allows you to run maximally complex Python ap…

Thank you for the very thorough answer :)

Re: GraalPy – A high-performance embeddable Python 3 runtime for Java

#150

Post by igouy »

Rochus wrote: post #128
masklinn wrote: post #127

Earlier quoted context omitted.

> That's why, for example, the benchmark implements its own collections, because we want to know how fast the interpreter is. Otherwise, as you have noticed, the result is randomly influenced by how much compute a particular application can delegate to the FFI. That sounds like the exact opposite of what I would want as a user of the language: the benchmark completely abstracts the actual behaviour of the runtime, cl…

If you don't know exactly what you are measuring, the measurement is worthless. We must therefore isolate the measurement subject for the measurement, and avoid uncontrollable influences as far as possible. This is how engineering works, and every engineer should also be aware of measurement errors. In addition, repeatability and falsifiability of the experiment and conclusions are required for scientific claims. The…

Their point seems to be a tautology: If what you are measuring is worthless, the measurement is worthless.

Whether the measurement is in-some-sense formally correct or not is another question.

Post reply on HN