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

Рет қаралды 7,319

Күн бұрын

Explore the world of data serialization formats as we delve into the question, Is PKL the Ultimate Data Format? In this video, we embark on a journey to discover the strengths and weaknesses of Apple Pkl. We put it up against popular contenders like YAML, JSON, CUE, and others, to assess its usefulness.
#Pkl #CUE #YAML #JSON
Consider joining the channel: / devopstoolkit
▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬
➡ Gist with the commands: gist.github.com/vfarcic/06559...
🔗 Pkl: pkl-lang.org
🎬 Is CUE The Perfect Language For Kubernetes Manifests (Helm Templates Replacement)?: • Is CUE The Perfect Lan...
🎬 Is Timoni With CUE a Helm Replacement?: • Is Timoni With CUE a H...
▬▬▬▬▬▬ 💰 Sponsorships 💰 ▬▬▬▬▬▬
If you are interested in sponsoring this channel, please use calendar.app.google/Q9eaDUHN8... to book a timeslot that suits you, and we'll go over the details. Or feel free to contact me over Twitter or LinkedIn (see below).
▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
➡ Twitter: / vfarcic
➡ LinkedIn: / viktorfarcic
▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬
🎤 Podcast: www.devopsparadox.com/
💬 Live streams: / devopsparadox
▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬
00:00 Introduction to Pkl
03:32 Pkl in Action
10:38 Pkl Pros and Cons

Пікірлер: 43

@cowgod77 3 ай бұрын

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.

@IvanRizzante 3 ай бұрын

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!

@harshthakur7215 3 ай бұрын

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

@zekodun 3 ай бұрын

If one needs to "Generate" json or yaml then just use a 3rd gen language like python, bash, or golang. Heck one can just use jsonpath or yamlpath. But keep in mind yaml is meant to be DRY with Anchors and included as data for formats like markdown not as a config or dataset language.

@DevOpsToolkit 3 ай бұрын

It is also used to communicate the desired state to kube API... That state is data.

@zekodun 3 ай бұрын

@@ZiggleFingers Do believe one completely missed the point. We solved this sort of issues back doing the micro-pc days (e.g. 1965-1978). Three design points that still work today are: 1. Write programs that do one thing and do it well. 2. Write programs to handle text streams, because that is a universal interface 3. Write programs to work together. Expect the output of every program to become the input to another, as yet unknown, program. Config should not be needed. in the rare case it exists then it is only for setting parameters not passing data or managing state. Anything else is RPC *and* bloat. Also, both dns srv/mdns and 12factor apps address most arguments one would come up with on environment variables, connection strings, tokens, etc. Again these are just means of transferring state that really should be parameters/arguments to the program.

@MarcusXPX 3 ай бұрын

@@zekodunconfig should not be needed? How do you store the desired state configuration for IAC? Or you want to render IAC obsolete? That's silly ..😅

@zekodun 3 ай бұрын

@@MarcusXPX Then tell us, what is the most atomic part of "IaC"?

@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.

@DryBones111 3 ай бұрын

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 3 ай бұрын

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.

@Requiem100500 3 ай бұрын

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

@chrishillery 3 ай бұрын

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.

@DevOpsToolkit 3 ай бұрын

What do you think of Pkl?

@timothywcrane 3 ай бұрын

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 3 ай бұрын

@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 3 ай бұрын

@@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 3 ай бұрын

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 3 ай бұрын

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

@robpearce 3 ай бұрын

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

@joebowbeer 3 ай бұрын

Is kcl-lang another option in the CUE space?

@DevOpsToolkit 3 ай бұрын

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 3 ай бұрын

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 3 ай бұрын

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

@DevOpsToolkit 3 ай бұрын

@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.

@perarneng 3 ай бұрын

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 3 ай бұрын

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.

@platin2148 3 ай бұрын

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 3 ай бұрын

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?

@keypresspunisher 3 ай бұрын

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 3 ай бұрын

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 3 ай бұрын

@@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.

@zekodun 3 ай бұрын

Wat da fuq!!! did we learn *NOTHING* from the horrors of XML or any blood other data structure/exchange as a language?! Pkl is just apple's version of HCL. HCL is just a bloody opinionated template engine. Yaml opinionated data format. It all compiles down to JSON and JSON is just a bunch of C Structs. If someone needs to introduce a schema structure, branching logic, and a full language *AS DATA* they failed the XKCD927 test. Stick to RFC and ISO standards then one doesn't need to spend so much mental capacity on tech gymnastics and spend more time getting work done.

@DevOpsToolkit 3 ай бұрын

Does that mean that you write Json specs for kubernetes directly?