Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can you imagine the progress we could've made by now if people just tried to use the right tool for the job instead of trying to make the wrong tool good enough?

All the time spent trying to optimize JITs for JavaScript engines, or alternative Python implementations (e.g., PyPy), and fruitless efforts like trying to get JVMs to start fast enough for use in cloud "lambda function" applications. Ugh...



> and fruitless efforts like trying to get JVMs to start fast enough for use in cloud "lambda function" applications

This is how we got Graal, why would you call it "fruitless effort"?


Okay, so "fruitless" wasn't the right word. If you try to build an actual house out of LEGO bricks, you can eventually succeed and therefore the endeavor was technically "fruitful." I think I should've described it as "wasteful" effort, or as an inefficient use of brilliant minds' time.

For my specific example of JVMs on lambdas, I wasn't really thinking about GraalVM. I was more thinking of all the hacky, fiddly, things that people were doing to "warm up" their JVM-based lambdas. Like some of the stuff described in this article I just randomly grabbed from a web search: https://medium.com/@marcos.duarte242/keeping-your-aws-lambda...

The reality is that JVM languages were just the wrong tool for the job of writing short-lived applications.

Even though I wasn't really thinking about GraalVM, it might not be shocking that I don't really like it either- for the same kind of reason(s). Java was designed as a fairly dynamic language: you have runtime reflection, dynamic class loading (hot swapping), and various other (admittedly niche) features. So, Java code destined for GraalVM has to be written differently than Java code destined for a standard JVM runtime, which is an inverted way of saying that the nominal goal of GraalVM is technically impossible (you can't, generally, write a native compiler for the Java programming language). So, again, we're taking a language that was designed and optimized for specific runtime properties and we're forcing that square peg into the round hole of AOT compilation. You want native performance? Use a native language!

It feels like someone trying to design a hammer to also be a really shitty screwdriver. Why not just use a hammer sometimes and a screwdriver other times?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: