This is great, I'm in love with the idea of something like Jython for Python 3. I want to love python more than I already do, and with type checking sorta creeping into the understanding of the userbase, I'm hopeful still.
I'm gonna try this out later and see what kinda numbers this thing can actually do.
Edit: hm, this hasn't actually been touched since 2018, that's not good.
Looks like this was supported by Oracle's Zurich team, and they probably decided to stop working on this project back then (they were responsible of the vast majority of the contributions before then)
From what I can see in ZipPy it's leveraging Jython at least partially, whereas graalpython wasn't (presumably written as a fairly clean implementation?)
ZipPy, the initial implementation of Python on Truffle, was an intern project developed by Wei Zhang [1] while doing his PhD at UC Irvine, and continued by other students for a while. It was later re-implemented from scratch by an Oracle Labs team. I think that the main reason for a clean re-implementation was that the Truffle framework had evolved enough where it was easier to start from scratch than to rebase. Also, ZipPy was reusing the Jython parser, whereas GraalPython is using ANTLR [2].
Looks abandoned - last issues are from 2017 and the build system fails when you run it, it points to resources online that no longer exist. Why did this get posted?
If only Oracle would stop gimping performance on the free version of GraalVM. The best optimizations, the ones that make it faster than OpenJDK, are $$$$$. And they're trying to replace OpenJDK's compiler with Graal, to convert Java back into a language where performance costs money.
Imagine if the free version of gcc or clang had gimped performance. The whole purpose of a compiler is to build code that's as performant as possible.
They have a Scala-heavy codebase that benefits from the of the optimizations C2 in OpenJDk doesn't do. In the general case, Oracle optimized free Graal to the point it was just on-par with OpenJDK and made the additional optimizations commercial only
So you agree it’s on-par with OpenJDK, and admit sometimes a lot better in practice, and it’s free... and you’re still not happy simply because there exists something even better which isn’t free?
It's an official implementation, the beginnings of a segment of the ecosystem. A different Java compiler was what Google started with on Android... Look at the mess they created now.
If code runs differently on official platforms Commercial Graal can build a moat where code X doesn't work well on OpenJDK. Eventually you end up with code that works on OpenJDK and Graal EE, and a subset that only works well on Graal EE.
This is why, in my mind, compilers from official sources should always be free. Since Graal EE performs better there's nothing stopping Oracle from pulling a Chrome. Take all the market share then a few years later use your market power to start fucking with the ecosystem
It implements the same Java specification as every other Java implementation. It's a conforming implementation.
How can an extra implementation of exactly the same standard possibly be a bad thing? This is what we want isn't it? Multiple implementations innovating to improve while keeping to the same spec? So if you don't want to pay for Graal EE it doesn't matter because your code still runs everywhere, and because CE is as good as OpenJDK you're no worse off in any case.
Or are you saying they're going to break the spec? Well that's just a baseless speculation so not useful to talk about in my opinion.
We're really lucky that Oracle are investing so much money on pushing the limit of Java performance, and that they make the vast majority of it open source. Few companies have the money and institutional knowledge to do this.
Imagine if the free version of gcc or clang had some of the performance improvements that only come with forked versions available from OEMs.
This free beer mentality is damaging for software tools, thankfully one can still work for corporations where money is no problem and thus have access to nice tools.
When tooling is tucked behind glass doors, your chances of getting a useless SAP guy is much higher. From a business perspective, I'd rather have all the tools available for anyone.
Free beer tooling is what gives us the performance of JIT and GC implementations on MRI Ruby and CPython, or the RAD capabilities of native toolkits aimed at GNU/Linux desktop, because living from donations and Patreon can only do so much for a few selected lucky souls.
I rather prefer that fellow developers get paid the same way I enjoy being paid as well, and yes I don't have any issues being that SAP guy if it much be so.
Being useless or not, is a matter or perspective, and I find sad that in forum tailored for creating new business, so few people are willing to pay for their tools.
I'm down with paying for tools when creating value, not when learning. We probably even agree. I do not expect many experts to appear at my doorstep if the tool is proprietary. SAP was an example of that.
Isn't the biggest issue that alternative Python implementations (pyston, pypy) have to implement all the quirks of CPython and compatibility with C-Extensions? Since there is no written standard and libraries rely on CPython behavior. Making things like Numpy etc. work, that heavily use C, seems really hard for jitted implementations.
This is why Graal languages virtualise C extensions by interpreting them, allowing them to appear to meet a fixed C interface with quirks but really being implemented more efficiently.
reply