Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraalVM

graalvm.org

Post reply on HN
Print view View original

61–70 of 108 posts

Re: GraalVM

#61

Post by monadic2 »

tosh wrote: post #58
TimTheTinker wrote: post #26

Earlier quoted context omitted.

As far as I know, Truffle is able to do some absolutely incredible compile-time optimizations —- reaching deeply into what we would normally regard as strictly semantic territory. (For an example, see some of the optimizations done by TruffleRuby for things like `myArray.sort.first` - which it apparently optimizes by terminating the sort as soon as the first element is sorted to the front of the array... and all that…

I'm not sure how it would terminate sort early, my initial assumption was that for small arrays there might be special-casing? this seems to be a related thread on twitter: https://twitter.com/ChrisGSeaton/status/1001582169578524672

Are you unsure about the runtime considerations or how the compiler would infer the necessary optimizations?

Re: GraalVM

#62

Post by pjmlp »

Hitton wrote: post #54

I have hard time being deeply invested in GraalVM considering that the most interesting stuff tends to be kept proprietary (e.g. profile-guided optimizations).

Do you also have the same issue with LLVM, given the goodies that Apple, Sony, ARM and many others don't upstream?

Re: GraalVM

#63

Post by pjmlp »

amelius wrote: post #57
Hitton wrote: post #54

I have hard time being deeply invested in GraalVM considering that the most interesting stuff tends to be kept proprietary (e.g. profile-guided optimizations).

Also, if you're like me, you simply don't want to deal with the law firm called Oracle.

What about the law firm Apple?

Re: GraalVM

#64

Post by pjmlp »

mikkom wrote: post #52
galaxyLogic wrote: post #27

Earlier quoted context omitted.

> Startup time? Granted. Anything else? Not so much. Startup time matters a lot especially for Java applications. The reason Java never got to the desktop (including browser) I believe was the startup time. Startup time matters a lot also for micro-services. A 2nd great benefit of GraalVM I think is it makes it easy to integrate programs written in different languages, say Node.js and Java for instance.

> The reason Java never got to the desktop (including browser) I believe was the startup time. I think it's mainly the fact that it has always been very difficult to create executable files. Running java requires you to install the given version of JRE instead of just downloading an application and starting it.

It was always very easy, just package the JRE with the application, use an installer like any other desktop application, or buy one of those commercial AOT compilers available since the start of century.

Re: GraalVM

#65

Post by jbister »

andretti1977 wrote: post #40

I'm happy with language interoperability as a concept but how can i mix java and js in the same codebase with graalvm? And would it make sense? What are the advantages of this approach?

You can use it for doing server side rendering of React or other JS framework components. I have a VERY rough repository[0] where I tested this out a while back. The way I did it was to export functions on the global object in JS[1] which could then easily be called from Java code[2]. I'm sure there's a better way to accomplish the same thing.

What I found interesting with this approach is that it allows you to do server side rendering without needing a separate server and without needing any third party dependencies aside from GraalVM itself.

0. https://github.com/JackBister/javalin-preact-archetype

1. https://github.com/JackBister/javalin-preact-archetype/blob/...

2. https://github.com/JackBister/javalin-preact-archetype/blob/...

Re: GraalVM

#66

Post by cmkrnl »

pjmlp wrote: post #62
Hitton wrote: post #54

I have hard time being deeply invested in GraalVM considering that the most interesting stuff tends to be kept proprietary (e.g. profile-guided optimizations).

Do you also have the same issue with LLVM, given the goodies that Apple, Sony, ARM and many others don't upstream?

Good point, actually. At least for me, reveals a blind spot. Out of sight, out of mind.

Re: GraalVM

#67

Post by rbanffy »

rubyfan wrote: post #60
nathell wrote: post #56

Earlier quoted context omitted.

[3] is made possible thanks to a variation of the idea called "Futamura projections": https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...

I read that as Futurama and when I clicked through was expecting to see a picture of Fry or Hypnotoad as some time travel concept as inspiration. Even better, when I clicked through I read it the first time and thought “wow cool someone’s last name is Futurama” then I read it again haha.

"Dyslexics of the world, untie!"

Re: GraalVM

#68

Post by rbanffy »

pjmlp wrote: post #62
Hitton wrote: post #54

I have hard time being deeply invested in GraalVM considering that the most interesting stuff tends to be kept proprietary (e.g. profile-guided optimizations).

Do you also have the same issue with LLVM, given the goodies that Apple, Sony, ARM and many others don't upstream?

That's the most wonderful thing of GPL'ed software - enforcing the no-selfishness rule.

Re: GraalVM

#69

Post by rurban »

amelius wrote: post #57
Hitton wrote: post #54

I have hard time being deeply invested in GraalVM considering that the most interesting stuff tends to be kept proprietary (e.g. profile-guided optimizations).

Also, if you're like me, you simply don't want to deal with the law firm called Oracle.

And more worrying: Java, the language.

Re: GraalVM

#70

Post by rbanffy »

pjmlp wrote: post #24
eyelidlessness wrote: post #3

So... the polyglot featureset is simultaneously terrifying and super impressive.

While impressive, that was one of the premises for the CLR, and both build on top of language environments from mainframes.

> both build on top of language environments from mainframes

They also had virtual machines and five nines before it was cool.

Post reply on HN