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

Pkl, a Programming Language for Configuration

pkl-lang.org

Post reply on HN
Print view View original

591–598 of 598 posts

Re: Pkl, a Programming Language for Configuration

#591

Post by mieubrisse »

rockwotj wrote: post #570
mieubrisse wrote: post #562

Earlier quoted context omitted.

A big problem we've hit with allowing users to write Typescript (or any other general-purpose programming language) for our product is that it's too powerful. Observationally, it seems that all that power eventually gets used, and then you end up with config that has complex interfaces, or becomes non-portable because it's doing arbitrary file reads, or is non-deterministic because of an ill-advised call to random or…

I feel like this is what code review is for. Isn’t this also possible with your application code? How do you prevent that? As for I/O concerns, run it in CI with deno and ensure there is no I/O

Yep, application code can have the same problem! The difference is that application code lives "inside the abstraction" of the program, and is viewed and edited by a much smaller set of developers.

Configuration, by contrast, sits at the seam between two systems. It's the top-level parameterization of the abstraction, and behaves more like an API. E.g. imagine if the only way to configure Kubernetes or Docker were in language-specitic bindings - there was no such thing as a YAML lingua franca.

Re: Pkl, a Programming Language for Configuration

#592

Post by wtetzner »

Fischgericht wrote: post #411
afavour wrote: post #405

Earlier quoted context omitted.

That strikes me as a very uncurious perspective. There’s absolutely nothing that could be improved about configuration files? An 87MB binary feels like a very arbitrary measure of worthiness.

ONE actual standard that everyone uses would be fine. For non-tree (nested) configurations, an ini file would do. It's a standard that worked well in 1990, and still does today. For nested data, it doesn't matter to me if it's JSON, YAML, TOML or whatever. Just agree on ONE format. TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due…

> ONE actual standard that everyone uses would be fine

Sounds like a social problem. How do you get _everyone_ to agree on anything?

Re: Pkl, a Programming Language for Configuration

#593

Post by dbu21 »

paufernandez wrote: post #476
krajzeg wrote: post #109

Earlier quoted context omitted.

> ...GraalVM Truffle framework... Futurama Projections... I know it's partly on me for not knowing the domain, but I honestly suspected somebody is trying to make fun of me with some concentrated technobabble. Especially since I wouldn't expect the topic (configuration languages) to require complex mathematical machinery to work with. Now I have something interesting to dig into.

The best video I know about this stuff is "Compilers for free" by Tom Stuart ( https://youtu.be/n_k6O50Nd-4 ). It is hilarious at one point. Brilliant.

Fantastic talk! Thanks for sharing.

Re: Pkl, a Programming Language for Configuration

#594

Post by iainmerrick »

SureshG wrote: post #588
iainmerrick wrote: post #285

Earlier quoted context omitted.

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 nativ…

>"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…

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.

Re: Pkl, a Programming Language for Configuration

#595

Post by bsdpufferfish »

jhardy54 wrote: post #583
bsdpufferfish wrote: post #527

Earlier quoted context omitted.

gcc main.c Of course tinkerers made some tools you can tinker with as time went on, but you don’t have to let those interfere with velocity, just like I will not be using configuration languages.

Do you mind linking me to some large C projects that don’t use make/autotools/etc?

stb libraries

Re: Pkl, a Programming Language for Configuration

#596

Post by jhardy54 »

bsdpufferfish wrote: post #595
jhardy54 wrote: post #583

Earlier quoted context omitted.

Do you mind linking me to some large C projects that don’t use make/autotools/etc?

stb libraries

So… novelty single-file libraries? I’m not sure that “it works if you only have one file” truly supports your argument.

Re: Pkl, a Programming Language for Configuration

#598

Post by Bost »

panzi wrote: post #544
iso8859-1 wrote: post #511

Earlier quoted context omitted.

Guix/Nix can use dynamic linking without risk since they know the exact dependency closure. It's not fair to compare a statically linked executable to a dynamic one.

Right, so its still just about 9 MB: guile=$(readlink -f $(which guile)) sizes=$({ echo $guile; ldd $guile|grep /|sed 's+^[^/]*\(/[^ ]*\).*+\1+'; }|xargs -n 1 readlink -f|xargs du -ab|cut -f 1) sumsize=0 for size in $sizes; do sumsize=$((sumsize+size)); done echo $sumsize Gives 9041632 here.

Thanks for the snippet. Now I have a recipe how to calculate the size of a binary file, plus the shared objects, i.e. the so-file(s), it requires directly.

Now I just need to extend your snippet so that it works recursively. A shared object can require other shared objects.

Post reply on HN