Is Pkl the Ultimate Data Format? Unveiling the Challenger to YAML, JSON, and CUE

[@cowgod77]

Thanks for taking a deeper look at this. You definitely seem to rave about Cue -- I should revisit it. Your earlier video on it made it sound quite interesting, but when I tried to dip my toes in it, I quickly felt overwhelmed. I'll need to give it another try, because it sounds like it scratches an itch I have.

[@harshthakur7215]

I would be more interested if it could read JSON, TOML, HCL, etc and translate it to pkl and then to language bindings. That would've felt like a step in the right direction for config format agnostic tooling

[@DryBones111]

Is Pkl also designed to be authored and distributed by platform teams? Something I have discovered about CUE is that while it is difficult to learn and write your abstractions as a platform developer, it is extremely simple to use those abstractions as a platform user. Easier than writing JSON given the strict validation and trim functionality.

[@DevOpsToolkit]

It serves a similar purpose as CUE, Jsonnet, ytt, Helm, etc. They are all designed to help defining data structures and to output results into more verbose (but easier to read) formats like YAML or Json. Now, I would argue that platform users should not use those abstractions, at least not directly. Platform developers should, first and foremost, be building APIs behind the services they are exposing. Those APIs are, more often than not, declarative so interaction with them is usually through YAML or Json. If those APIs are simple enough and tailor-made for platform users, there will be no need to use anything more complicated to invoke them.

[@DevOpsToolkit]

What do you think of Pkl?

[@timothywcrane]

I think that they might have problems after naming it after the recently discovered insecure Python PKL (switch to safetensors). I confused it with this when first watching and had to look up the difference.

[@DevOpsToolkit]

@timothywcrane When I first heard about Pkl, I looked for a Nix package, saw that it is something related to Python, and gave up on it. It took me a while to figure out that those are not related. So yes, the name is bad.

[@timothywcrane]

@@DevOpsToolkit I almost screamed no, use safetensors without context... glad i took a second look. I used to use it a decade or so ago for php/python binding (through phpPickle). Now we use it to ship LLMs and other AI models for inference with python. But is "unofficially" deprecated in the AI community for safetensor filenamed models. love your vids BTW. Watched more avidly a year or so ago when K8S was on the mind more. I never found a good single PC replacement that could be used in minor production. My dev box is also production at home.. Podman seems to suffice but I would love to find something that would scale "when I need it to" outside of my own system (especially in the GPU as a service world) a little better. I appreciate your work. Thanks.

[@gowthamg6760]

I feel like Pkl is a unwanted add on layer created by Apple on top YAML , for dynamic creation of YAML we can use any of the existing available tools like cue, kustomize or a scripting language like python.

[@DevOpsToolkit]

@gowthamg6760 I guess that the "why?" point in my cons.

[@IvanRizzante]

Thanks for another great video! I am biased, I still work on jsonnet for anything that doesn't have an Helm chart natively. Nevertheless I still watch with interests all the other languages coming out around yaml world, who knows, maybe I'll change my mind one day!

[@joebowbeer]

Is kcl-lang another option in the CUE space?

[@DevOpsToolkit]

Kcl is very interesting but it's documentation is even worse that Pkl. Once a month I give it a try, get stuck on something, fail to find the solution in the docs, and write a task for myself to try it again later.

[@DryBones111]

I'm also curious about this one. On my quest to find the right configuration tool for a project, KCL is the last contender over CUE.

[@joebowbeer]

I just read the blog about support for KCL functions in Crossplane. I like the look of inline kcl-function.

[@DevOpsToolkit]

@joebowbeer kcl is awesome, but I'm still on the edge when using it as inline functions mostly due to lack of support for that in IDEs. The support kcl, but not when it is inside yaml. On top of that, i did not find a way to write a whole composition in kcl with kcl also as inline functions.

[@ZeroUm_]

If you're going to use some form of human-readable data serialization in your programs, I'd try to find a library that can read and write every popular format, and give you a standard interface. No need to bother if X or Y is better.

[@DevOpsToolkit]

I'm more focused on transforming code to some data format like yaml and Json to send to some API (e.g. kubernetes), than code if my app being able to read some data. The latter problem is mostly solved through existing libraries.

[@platin2148]

Not using Yaml that stuff is terrible to parse and is there even a valid standard? The time when you require to generate your config which generates code is basically the time at which you should question what you are doing.

[@DevOpsToolkit]

I'm not sure I understand. Are you saying that APIs should not accept JSON or YAML but something else? If they should access Json or YAML, we have to write or generate that. Whether it should be written or generated largely depends on the size and complexity. On the other hand, if APIs should accept something else, what is that?

[@Requiem100500]

good ol' HCL never failed me in both simple and complex scenarios

[@chrishillery]

The examples here really made me think of Terraform, yeah. I think that's a problem, really - if Pkl serves a different purpose than Hcl, it should *look* different. Otherwise it just introduces confusion.

[@perarneng]

Why not go all the way and do cdk8s instead of trying so hard to create some kind of hybrids that are bad programming language but pretty complex configuration languages?

[@DevOpsToolkit]

I used cdk8s mostly with Go, and it's really bad. The way original JS code is translated to Go libraries is bad. JS libraries are much better. Not sure about other language. On top of that, there is always value in having languages specialized in specific types of tasks. That's why Go is good for some things, JS for others, etc. In this case, that task is to deal with data structures. The problem is that learning additional languages (including DSLs) is a chore so the question is whether the time invested in learning them pays of through the benefits we have by using more specialized languages. I, for example, tend to use CUE which is based on Go so the learning curve was slightly lower for me than it might be for others. Pkl, on the other hand, might be easier to learn for Java developers.

[@twenty-fifth420]

I got tired of asking a Swift question to any AI that it gave me XCode instructions, that I began to build my own build system. I have a front-facing XML document that is like a makefile or a meson.build. And I am not going to lie, I found out about this and I feel like apple just found a way to reel me back in and I don't even have a Mac! I develop Swift on Linux like any freedom respecting pirate! I still will keep the XML parts, but I think PKL was invented because apple probably hates XML underneath their xcode lol or so is my conspiracy (at least I think xcode proj are XML based.)

[@robpearce]

ugh, X is the new Y. Unlikely. Besides, don't even think cue got momentum yet

[@keypresspunisher]

damn it more languages to layer on top of other layers. developers who create these type of crap seriously need to use kiss. old school developers were able to create complex applications that could fit in a floppy. What I hear now a days is that, simple projects that should be with less effort are more complex because we need terraform, helm, ansible, node etc just to create an application or even a feature. I can't wait to hear one day a developer say, "we would need ketchup, mustard, pkl with salt to deploy your solution, no problem."

[@DevOpsToolkit]

What do you mean by old school developers. Those working with C and Fortran, creating apps that can serve up to 100 concurrent requests and running on mainframe, etc. I started my career near the end of that era (90s) and I can safely say that the type and the scale of the problems we are solving today is completely different. Those "old school" devs were indeed capable of doing things we cannot do today but they would not be able to work on the problems we are solving today unless they stopped being "old school" developers. All that does not mean that Pkl is great but, rather, that it is solving a different type of problems.

[@savire.ergheiz]

​@@DevOpsToolkitWhat are you talking about. Programming were never changed. Its just getting fancy. Don't you know that hardware wise x86 are getting obsolete now its coming back into more simpler arm based. Web apps are getting back into static html again. You just don't make sense. A godlike old school coder can tackle all problems. They just transcends with time.