What is the use-case for GraalPy? To be honest I don't understand why would anyone want to use it.
Besides all the nice answers given by others, a big one was not mentioned: performance! Graal can do pretty advanced JIT-compilation for any Graal language, plus you can mix-and-match languages (with a big chunk of their ecosystems) and it will actually compile across language boundaries. And we haven’t even mentioned Java’s state of the art GCs that can run circles around any tracing GC, let alone the very low throu…
GraalPy – A high-performance embeddable Python 3 runtime for Java
61–70 of 151 posts
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#62If you're into that sort of thing.
Self-interest disclosure: I'm a major contributor and heavy user.
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#63Earlier quoted context omitted.
Besides all the nice answers given by others, a big one was not mentioned: performance! Graal can do pretty advanced JIT-compilation for any Graal language, plus you can mix-and-match languages (with a big chunk of their ecosystems) and it will actually compile across language boundaries. And we haven’t even mentioned Java’s state of the art GCs that can run circles around any tracing GC, let alone the very low throu…
I guess for pure python applications, they'd rather throw more hardware at the problem than messing with the JVM.
Also, what is “messing with the JVM”? That’s like one of the most battle tested technologies out there, right next to the Linux kernel.
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#64Earlier quoted context omitted.
I guess for pure python applications, they'd rather throw more hardware at the problem than messing with the JVM.
For serial workloads it’s very very hard to scale by hardware, though. CPUs aren’t getting 2x faster as they used to. Also, what is “messing with the JVM”? That’s like one of the most battle tested technologies out there, right next to the Linux kernel.
The unfortunately common irrational aversion to JVM aside, there's also the fear of "using it wrong".
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#65FWIW we've had full Java/Python integration in Clojure for awhile now, courtesy of Chris Neurnberger and libpython-clj: https://github.com/clj-python/libpython-clj If you're into that sort of thing. Self-interest disclosure: I'm a major contributor and heavy user.
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#66What is the use-case for GraalPy? To be honest I don't understand why would anyone want to use it.
Picture working for a big, non-tech corporation. Your BU only does Java because it has always been thus and Jeff the SVP is a law grad and doesn't want anything to change because of perceived risk. GraalVM allows smart people who have to work within such limitations to still write (mostly) the software they want while still vaguely relating it to Java for decision makers.
Everyone else has to write wrappers to interact with that blackbox. God forbid someone daring to even change the code, because it basically doesn't even need/use junit tests. Eventually the smart person gets bored and moves to something else, that tool then gets rewritten to Java in two days by someone else.
End of story.
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#67Earlier quoted context omitted.
I think GraalPython does have a GIL, see https://github.com/oracle/graalpython/blob/master/docs/contr... - and if by "there is no such thing on those platforms" you mean JVM/CLR not having a GIL, C also does not have a GIL but CPython does.
My mistake, as I assumed they took the same decision as jython and IronPython. https://jython.readthedocs.io/en/latest/Concurrency/#no-glob... https://wiki.python.org/moin/IronPython The difference between JVM, CLR and C in regards to parallel and concurrent code is that they are built for those kind of workloads, and have a memory model proper, hence not needing a GIL.
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#68Earlier 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…
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#69what's the advantage of this over JPype?
Re: GraalPy – A high-performance embeddable Python 3 runtime for Java
#70Earlier 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…
- Imports in Ruby seriously suck compared to Python. Everything requires into a global scope and an ecosystem like bundler which encourages centralizing all imports for your entire codebase into one file.
- Python has docstrings encouraging in code documentation.
Add common ecosystem things like the Ruby community encouraging generated methods, magical "do what I mean" parameters, and REPL poke-driven development, and this leads to the effect that Python codebases are almost always well documented and easy to understand. You can tell where every symbol comes from, and you can usually find a documentation entry for every single method. It's not uncommon for a Ruby library, even a popular one, to be documented solely through a scattering of sparsely-explained examples with literally no real API documentation. Inheriting a long-lived Ruby project can be a serious ordeal just to discover where all the code that's running is running, why it's running, where things are preloaded into a builtin class, and with Rails and Railties, a Gem can auto insert behavior and Middleware just by existing, without ever being explicitly mentioned in any code or configs other than the Gemfile. It's an absolute headache.
My dream language would be Ruby with Python-style imports and docstrings.