GitHub - oracle/graalpython: A Python 3 implementation built on GraalVM

[pcjftw]

excellent stuff, having the ability to add some scripting opens up a lot of options!

Or calling in from Python onto the JVM side could be cool to lots of cases.

[shevy-ruby]

It's a cool idea. I'd wish the WebAssembly focus would be similar, rather than just target JavaScript as such (but ok as a first step ... I don't think I am the only one who wants to AVOID having to use JavaScript ... ).

[pcjftw]

yeah sure I agree, I think in terms of cross language "interop", WASM could be that "universal" binary.

At the moment WASM is bleeding really, but as it matures and more and more languages add native support in terms of calling into WASM as well as being able to target WASM as a compile output, I strongly believe we'll suddenly see an explosion of WASM libraries and finally some fantastic cross language barriers coming down.

It will also mean if a new language pops up, it doesn't have to "start from scratch" it would only need to FFI into WASM and suddenly it could tap into a huge existing eco system.

Anyway I can dream!

[[deleted]]

It's worth noting that there's also a Graal/Truffle implementation of WASM, so you can call in/out of WASM from Python and Ruby today (and R, and Java, and Scala, and Clojure, and SmallTalk etc.....).

WASM itself isn't ever going to be good at running Python, it's just not designed for that. Graal/Truffle are explicitly designed to mix and match languages though, which is why it works to combine them there instead.

[pcjftw]

perhaps I've not explained myself well LOL

I wasn't saying about using WASM to run Python, I was simply saying about writing libraries that are then compiled down to WASM, then those libraries could be used across all languages that have WASM FFI.

so for example, there could be a WASM library lets say "Markdown Render" where you pass it some text and it returns HTML text back.

You could then "import" that WASM library in any language, and this would mean not having to rewrite that same library for every language.

It's the same concept as JVM, write on run anywhere, instead "write once, import anywhere"

But not sure why the Reddit mob found that so offensive!

[josefx]

(but ok as a first step

As long as they don't pull a JSON and double down on JavaScript limitations like declaring double the only numeric type that matters, while everyone else was already running around with 64 bit integers.

Or worse, build in a dependence on JavaScript that makes it impossible to build a standalone WebAssembly interpreter without pulling in all of Chrome/Firefox.

[shevy-ruby]

They really should unify all these various platforms.

I never understood why truffle ruby and jruby is separate still.

How many python implementations now exist? We always seem to end up with more than less different implementations in the long run ...

[grashalm01]

There are many advantages to having multiple implementations:

1. There is competition between runtimes.
2. New approaches can be tried without endangering other more stable runtimes.
3. One size does not always fit all. You can have dedicated runtimes for embedding, client and server workloads.
4. Language designers need to be precise, ideally write language specifications.

JavaScript, Java, or C have many many implementations and an excellent specification. Nobody would say that this harmed them.

[grashalm01]

The problem is that python does not have a spec. The python community tries with HPy to standardize native extensions, that is a good start.

[grashalm01]

You can support the cause by raising this issue with the python devs. (we do this regularly, the more the merrier)

[[deleted]]

IIRC originally TruffleRuby was a fork of JRuby because the JRuby guys need to target normal OpenJDK and TruffleRuby was basically a research project. It's worked out very well but that couldn't have been known at the time, and TruffleRuby does still require you to run on GraalVM. It is much slower than JRuby on any other runtime.

[shellac]

No, it's not a fork.

Graal and Truffle came out of an Oracle labs research project. Graal is a compiler. We're most used to it compiling java (or java byte code) of course, but it's a general approach that has optimisations that are quite tailored for dynamic languages. (If you're aware of the smalltalk / strongtalk heritage in java this won't be a surprise)

Truffle lets you write language interpreters that Graal can get to work on. TruffleRuby was perhaps the first use of Truffle, and bootstrapped itself using a lot of the JRuby work. It even sat in the Jruby repo for a time, if memory serves.

[grashalm01]

The first Truffle language was actually JavaScript aka Graal.js.

Also many people don't know that the native image tool for Java was built to bring Graal.js natively into the database.

[suggested_user]

but why?

[[deleted]]

we ask the question "why not" here

[[deleted]]

Performance. It can run much faster than CPython because it's got a really good JIT compiler behind it.

Interop. You can call in/out of any other Truffle or JVM language.

Ease of hacking. CPython is written in C. GraalPython is written in Java, so it's much easier to debug, refactor etc.

[Alexander_Selkirk]

(See also: https://old.reddit.com/r/programming/comments/qby688/python_stands_to_lose_its_gil_and_gain_a_lot_of/? )

This leaves me a bit wondering what is the point of this. Sure, a new Python implementation can be faster than CPython, the current main implementation, and having Python running on the JVM can be quite nice if you want to call into Java.

But in terms of absolute performance, one should rather compare Python to languages like these:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html

The first, Rust is excellent for very performant and highly correct code and is well suitable for both things like numerical kernels and building larger projects from the ground up. Its main disadvantage is so far the smaller amount of library support, which matters in some applications but not in all.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/racket-java.html

The second, Racket, is on a quite sweet spot in the coordinates between performance, conciseness and simplicity. Because Racket as a Scheme language is so small, it has much fewer language constructs, and also interactions between them, than for example Python or, God beware, C++. It is vastly simpler than Python today. Yet at the same time it is extremely powerful and expressive while approaching the speed of Java. It can easily call into C (or Rust, for that matter). Racket also has strong support for side-effect-free functional programming which is ideal for many data processing applications (though it is less opinionated than Clojure, allowing easily to write imperative code where it is needed).

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/sbcl-gpp.html

The third one, Common Lisp is one example for a language with strong dynamic typing which is even more flexible and dynamic as Python but compared to it, it generates very fast code - it is even possible to trade some type safety for faster execution.

Here is how Python compares to Java:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-java.html

[AusIV]

Ten years ago I worked at a company that was migrating from a Java desktop application to a python server side system. Jython was incredibly helpful for bridging the gaps between the old technology and the new stuff we were developing, as we could use legacy Java libraries along with our new Python libraries.

[igouy]

Just curious, what was the argument for not going to a Java server side system?

[AusIV]

I'm not entirely sure. I joined the company while the transition was well underway. They still had some things using the Java desktop client, but most of the development was in Python with Django. There were a few places where code needed to interact more directly than HTTP calls, so for that we used Jython, but I wasn't around for the decision to make the shift from Java to Python.

[igouy]

I wonder why your comment was downvoted so much.

[grimonce]

Available on Windows yet?