[pdpi]

As I understand it:

GraalVM is an alternate JDK that can, among other things, do ahead-of-time compilation for Java.

Truffle is a framework for building languages, that sits on top of Graal.

Futamura Projections are a particularly interesting use case for compile-time partial evaluation.

With partial evaluation you have static (known at compile time) arguments to your function, and dynamic (known at runtime) arguments.

When “your function” is an interpreter, and your static arguments are source code, the output is effectively a self-contained compiled binary.

When your function is an interpreter, and the static arguments are the source code for the interpreter itself, that “self-contained compiled binary” is now itself a compiler.

[iainmerrick]

That all sounds cool, but is any of that especially useful for a configuration language?

[usrusr]

If you want a tool to be able to generate executable validation from a schema, a compiler framework should come in handy.

It seems like they did not aim to make yet another mvp configuration language, but something that can scale across a wide range of usage scenarios spanning all the way from short-lived processes reading a number from a file to huge libraries of default/override hierarchies. Lack of universality sets an upper bound for the value of a configuration language, particularly when seen through the lens of configuring heterogeneous tech stacks.

[SOLAR_FIELDS]

I’m also curious, because Graal is pretty exciting stuff, what this might give over Jsonnet or Cuelang. It’s already a hard enough sell to try to get people to adopt these and they are much older and more robust than Pkl.

[iainmerrick]

I'm very wary of anything Java-based, having been burned by Java tooling in the past. I work on a few different Android projects and I have to switch between three different JDK versions depending on which I'm working on. What happened to "write once, run anywhere"??

I really like Pkl's comparison page, which includes its weak points as well! https://pkl-lang.org/main/current/introduction/comparison.ht...

Pkl’s native binaries are larger than those of other config languages.

It should be as fast and easy to use and reliable as something like esbuild, so I'd suggest they may want to rewrite it in Go like esbuild. I'm not a Go fan at all, but it clearly does some things really well.

[SureshG]

>"write once, run anywhere"??

You know that the code compiled using future version of java won' work in older versions..rt? I would like to know if any other programming language does that kind of thing.

> t should be as fast and easy to use and

How did you conclude that it's not fast? They are creating native binaries just like Go or any other AOT languages with GCs. Graal native images are as fast or faster than Go. Also it contains a REPL, that's why bigger size. So for CLI tooling as a developer using pkl, you won't see any difference if it's written in java + kotlin or golang.

[iainmerrick]

You know that the code compiled using future version of java won' work in older versions..rt? I would like to know if any other programming language does that kind of thing.

Of course, but what surprises me is the lack of backwards compatibility -- future JVMs refusing the run old code. I get that you have to deprecate old unsafe APIs sometimes, but it feels silly that I need three different Java versions for different Android projects.

They are creating native binaries just like Go or any other AOT languages with GCs. Graal native images are as fast or faster than Go. Also it contains a REPL, that's why bigger size. So for CLI tooling as a developer using pkl, you won't see any difference if it's written in java + kotlin or golang.

That's good! I thought you needed Java to run it.

I figured I should give it a proper try, so I just downloaded it. 105MB!! They're not kidding when they say it's big. I also checked bun (47.7MB) and esbuild (9.8MB) for comparison.

pkl does seem to start up pretty fast, though. 1.6s on the first run (presumably just the time needed to cache that big binary) and ~100ms thereafter.

[spullara]

There are reasons Oracle sued Google over Android and you just articulated one of them.

[iainmerrick]

It’s not Android per se that’s the problem, it’s that Android uses Gradle as a build system and Gradle uses Java.

The Gradle compatibility matrix is pretty complicated: https://docs.gradle.org/current/userguide/compatibility.html...

I’ve also used Facebook’s Buck build system, as an attempt to get away from Gradle, and it’s also fussy about JDK versions.

[bioballer]

Pkl is newly open sourced, but it not new. It's been used for years at Apple, and has been battle tested internally.

I'd actually say that our tooling in some ways is more mature. For example, I think our IDE experience (at least in JetBrains editors) is the best out there.

[Perepiska]

There is no trust in the words “we tested this internally.”

Apple employees can rate it as an old project among themselves, while it is more convenient for everyone else to rate the product from the moment of publication.

[saynay]

Looks like a more robust type system than Jsonnet (but less than Cue), with some amount of flow-control that Cue doesn't seem to support. I am not very familiar with Cue though.

[matheusmoreira]

> With partial evaluation you have static (known at compile time) arguments to your function, and dynamic (known at runtime) arguments.

That's pretty clever... How is this implemented in actual code though? I can't even begin to imagine how that magic machinery works.

[EPWN3D]

> Truffle is a framework for building languages, that sits on top of Graal.

wtf is Graal? That sounds like a supporting character from Beowulf.

[sgammon]

https://graalvm.org

Polyglot and native compilation enabled runtime for JVM, can run Js, Python, Ruby and more.