I spent a couple weeks trying to bolt this on to our setup to support a more serverless style approach. OpenJ9 (sadly) really didn't work out well, perhaps we run in a way they don't optimize for. Azul and OpenJDK's approaches helped - but it is quite intrusive (you need a profiling run), and the absolute benefits aren't that great. It's mostly doing classpath stuff at present, and not really AOT work on machine code (though that is in the pipeline).
All in all, I wasn't particularly impressed with the outcome. Obviously GraalVM has more headroom, but that's an even more intrusive change.
When compared with a Rust port of our service, the delta of the efforts is absolutely astronomical. Ridiculous performance, near-instant startup, radically less memory consumption. I mean - duh - but nonetheless, when I contrast the effort vs payback, it's very hard for me to want to invest so much in techniques that have so little payback (graal) when I can put that into an approach that leaves me in a much better place long-term.
If I had mountains of legacy, obviously I couldn't do that, but in my situation it seems like a much more attractive option.
> Ridiculous performance, near-instant startup, radically less memory consumption.
It seems like your use case is rather not a good fit for Java.
Java shines best with large applications, where more abstract source code is desired and when you care more about typical performance, not the worst case performance. And if you can afford the cost of all those benefits, which is higher RAM usage.
They were early movers and established a lot of the patterns in the space, but I just don't see them holding on to this lead. Spark/Hadoop is really so damn inefficient that something like DuckDB shows where that overhead is, and it's extreme in many cases.
What I don't understand is why they didn't build this project on top of DuckLake instead - from my shallow analysis they vibe coded up a fake Databricks in Python.
Not that I'd use it, I want to avoid Databricks - the Duck ecosystem is far more compelling for my modest needs, and handles local develop a lot better (IMO).
The issue is there are SO MANY people who stop at the conclusion "batteries are expensive, dirty, use rare materials and are fueled by slave labour" - this level of understanding is ubiquitous in my experience. What I never hear is "compared to what" - like how does the full lifecycle analysis of those batteries IN CONTEXT compare to the status quo?
Or the folks that extend that argument to "EVs are bad". Without even considering the energy mix that they rely on. If you're not even interested in doing a single ounce of research and thinking, you're not making a point - you're regurgitating corporate propaganda.
I have to suspect that there are so many because there has been a propaganda campaign against progress, I suspect as a branch of the fossil fuel PR to say that climate change is not real, what we are doing now is fine and we shouldn’t change anything.
We did this many years ago for remote First Nations sites with an energy monitoring startup I worked for - saving them enormous sums of money (and carbon!) in the process. It's actually quite amazing how low some of the low hanging fruit is once you start looking.
When did it become "alive"? GPT-3? What is the threshold at which we consider something to be living. Is this a matter of complexity alone?
How alive is a collection of a dozen transistors? A million, billion, trillion? We can't just claim something is alive without being very specific about _why_ we believe it to be alive. The article's suggestion doesn't even begin to mention that.
This kind of heuristic is actually extremely useful - and mostly what I try to develop over a couple weeks as the new models come out. I would love if we could get a fairly standardized take like this on the regular.
Of course we have far too many benchmarks (of questionable utility), but it would be helpful to get OpenAI's take on where it slots in, and how the landscape changes as these get rolled out.
Lucky for us, the embedded folks don't take security too seriously! You don't need to be a garden variety hacker when your LLM can handle the drudgery for you.
All in all, I wasn't particularly impressed with the outcome. Obviously GraalVM has more headroom, but that's an even more intrusive change.
When compared with a Rust port of our service, the delta of the efforts is absolutely astronomical. Ridiculous performance, near-instant startup, radically less memory consumption. I mean - duh - but nonetheless, when I contrast the effort vs payback, it's very hard for me to want to invest so much in techniques that have so little payback (graal) when I can put that into an approach that leaves me in a much better place long-term.
If I had mountains of legacy, obviously I couldn't do that, but in my situation it seems like a much more attractive option.
reply