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"??
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.
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.
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.
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.