Probably because they want people to freely maintain it. I hate corporations abusing open source, but putting a big price to the end user. Open source it's great when end users benefit from it. If open source is hidden under 20 meters of proprietary garbage, why is it any different then unpaid labor?
@@ck-dl4to NTFS had streams and that failed because people hate Metadata inside the file Metadata goes in the file system, the name is Metadata, extension and file type also is
I found it funny because usually if I wanted to pickle something, there was a better solution assuming I wanted my project to be scalable in some way. And to be fair, you're going to choose one or the other, and as far as I know there's no external programs that open pickle files directly so you'll just be opening Apple's .pkl with a text editor and not touching pickles directly anyways.
13:17 "Imagine if your JSON autocompleted and gave you errors when you were editing it" You don't even have to imagine, it's already a thing with JSON Schema.
Within the first 3 mins of this video, I was already screaming JSON Schema. It follows DRY principles, has validation, is standardized, can be transpiled to POCO code in various languages. And JSON Schema files can also be referenced in an OpenAPI/Swagger spec to generate code for entire API endpoints. But sure, Apple, do your own thing. Just like they are trying to build the next standard of podcasting when we already have a well-developed Podcasting 2.0 standard.
I work at apple, i joined when it wasn’t open source and i was very skeptical about PCL ( internal it’s called PCL instead of PKL) but it does solve a lot of problems and the IDE integration is great. It has completely replaced helm in our team, it’s much better. I hope eventually helm charts will also be published in PKL.
"Pickle" sounds like "Pickel" which is German for "Pimple". Can't wait to hear my coworkers say "Create a pimple file for this project!". For that reason, I'm out 😆
@@jhuglen You really need to take a nap or some shit man. It's either extreme sleep deprivation, an absurd amount of alcohol, or you're doped the fuck up on psychedelics. Either way, you need a break
Classes, functions, loops and annotations; surely they did not reinvent C# or Java?! So to prevent using, say, groovy to do this, we now need pkl. That's just replacing 💩 with new 💩. All this smells too much like XML with xml schema. But a bit better, because XML is a massive 💩🙃
Really i prefer to validate my jsonf config file in my code, i dont like this and i agree with you, whats with this trend of overcomplicating things....omg, for example in c# i could use a library like fluenvalidation an validate rules for my json's structure with rules like "port" is an int for example .... not needing to define a new language for that 🤣🤣
this, just writing the parser for this was probably some intern's whole summer and it only made the problem worse. JSON is from 2001 and it's not impressive to be slightly better than one part of it 20 years later.
@@duartecunhaleao but consider that what is 'valid' may change from consumer or other factors and I doubt you are going to skip server/app side validations anyways and just leave it to this config, so you will end up doubling the validations. Also validation should be close to the app code im reading/writing as it is crucial.
Cool idea, but I'm having a hard time understanding the actual use case. I have never found myself needing a language agnostic config, Both JSON and YAML have schema files which solves auto complete.
Regex makes this all the more cursed. Now you can have a string format language inside of a data format language which can now be directly processed inside of your application's language, which means you have a language in a language in a language. I am absolutely digging this! 😂
Strictly speaking, RegEx is not a language, it is a pattern matching syntax. What would a better alternative have been? Invent yet another string pattern matching syntax for Pkl?
@@jhuglen hey can you stop spamming replies with this nonsense… You are conflating two completely different things… Apple is forced by the eu to conform to certain standards that the eu has set, like using USB-C ports, but that doesn’t mean that the eu has “forced” them to make a config language they developed open source… Like.. I really don’t know what you mean by “eu forced them” or “only in eu” here
I would rather them put thos energy into fixing the crashing bug in Xcode. Or maybe decoupling that IDE and compiler from MacOS versions so you can work on old apps without having to switch to old Macs with old MacOS versions.
>old (anyhting) >Apple There is no backwards compatibility. There is no tolerance. You will work with the newest version, whether or not it makes sense.
Sooo... They didn't know Nix, Nickel, Dhall, CUE, Jsonnet or HCL existed and therefore had to create their own thing? :/ It doesn't even look that good tbh. But yeah, impressive that Apple open sources something. That doesn't happen very often.
@@jhuglen The EU just said you need user consent before you store data on their PC for reasons other than purely functional. The Industry could have just followed the Do Not Track setting, but they want your data. Not the EU's fault that sites are evil.
Dude this isn't as big of a problem in JS land. For JSON, we have schemas. For JavaScript and TypeScript, most packages come with a defineConfig out of the box, and if they don't, rest assured somebody has already published an NPM package for that purpose.
They thankfully realised that the only way to have it adopted is to not only open source it but provide extensions to major editors, even VS Code. It's a good call, if they tried to make something proprietary, it would die painfully. Pkl seems cool, but it smells of something that will be infamous for quirks and hard to make parsers like YAML. Time will tell I guess, I do like it and hope it catches on and ends up being good.
chatter getting worked up about "version conflicts in config files": that's literally just a thing. The config format (or parts of it) may change over time after all, and it's important to keep track of that. It's great if Pkl can encode these existing problems and provide editor support for solving them... tho I wonder what form that'll take in practice, if and how different versions of a config format might be supported at the same time.
When I saw a configuration language that is "a blend between a static language and a general-purpose programming language" I immediately thought of Nix, a language with similar ideas created for a similar purpose. Nix doesn't seem to do very well outside Nix and NixOS ecosystems though, and Pkl does seem easier to grasp.
Totally agreed - for my NixOS system that I have been using for almost 4 years now I am happy with the subset of the Nix language that I need to know, but even then it sometimes still is hard for me to understand the syntax. And for programmer that is not used to it I think it is harder to fight with some of the constraints that you will run into when using nix in a very dynamic ecosystem: in the company I work for we are using it e.g. for building some JavaScript stuff and just the amount of work it takes for _some_ of the dependencies to be packaged is just insane (but to be honest, so is what those dependencies are doing on installation...). So yes - I really love NixOS, but I personally am sometimes struggling a bit with the nix language (yes - because I don't use it (or something similar) that often)
Why they need validation in a config file? My program can read the file and tell the user what is wrong. I don't need to learn a new scripting language for that. And if you config file gets too big I want to use a real programming language to create it anyway. Plus source control.
All the Python folks are hissing about this (don’t blame ‘em, they’ve been using “pickle” for serialization for ages). Anyway - I wonder if at Apple, all their Kubernetes cluster manifests are written in Pkl files. Hmm… that’d be interesting to look at!
Had not heard of DHall or Nickel. Just found their websites and notice that while DHall has a VS Code plug-in, they have no support for JetBrains IDEs. So for that reason alone Pkl is more attractive to me, since I'm spend most of my days in GoLand.
So C macros for config files? something like Cmake? This is just another syntax to add to the collection I have to use once every few weeks. Between all these scripting languages, config formats, CLIs, programming languages, etc we are expected to know is nearing 100+.
you can actually use C macros in any languages, but nobody does it because it would confuse newbies who have no idea what a preprocessor is EDIT: also your IDE would complain about syntax errors lol
So, they created Cascading Configuration Language; they should have named it CCL. Given how maintainable the seemed-like-a-good-idea-at-the-time CSS turned out to be, I am not so sure that we should consider them creating a cascading configuration language to be a good thing... 🤷♂️ #jmtcw
Am I the only one that thinks this would be creating more work and costing more time than it saves? It just seems awfully redundant. Maybe it's just because of the nature of what my projects usually are...
I hate languages like this because they have weird syntax and are gimped in some stupid way. If your config situation starts calling for variables, logic, data structures, type checking, loops, a compile step, and a fucking package manager... you are writing code. PLEASE just use a general purpose programming language at that point. This is how we end up with MSBuild XML
No, thanks. This is like the XKCD comic about the new standard. JSON is mostly fine. JSON needs improvements but it doesn't need to be replaced. I regret clicking on this video.
Nope. This is the last thing the industry needs. Sensible consumers avoid their overpriced products, and they should also never touch an apple technology that tries to get into our workflow. "FOSS" or not. No more corporate closed source proprietary. Snap out of it people, development isn't fashion.
As a Typescript developer i don't see much value in this, because a pkl file have roughly the same lines of code of a regular js/ts file used for configuration, but using js/ts doesn't need to install additional binaries or dependencies. However i can see some potential for more complex languages like Go/Rust/Java/etc. that are not suited for small "scripts" since they take in account stuff that you don't care when creating a configuration file such as pointers, packages, namespaces, classes, the borrow checker, constructors, errors handling.
> but using js/ts doesn't need to install additional binaries or dependencies Huh? What world are you living in where JS and TS doesn't require binaries or dependencies?
@@recepciftci2642 What computer? No computer comes with NodeJS preinstalled. You may have Docker images, but then it makes his initial point moot. Plus you'd still need to add TSC compiler as a dependency. That is besides the point, it's comparing apples to oranges.
@@dealloc I will help you understand the comment. The comment did not mean that JS and TS doesnt require binaries / dependencies to be installed, the commentor was talking about simply using JS/TS files as a configuration file, thus not having to install any other binaries related to configuration management tools. Sometimes its okay to assume things and not take everything literal, especially in a world in which english is a secondary or tertiary language for many people. Perfect grammar is something alot of us wish we'd have. Sometimes we slip up, and the meaning of a sentence might differ from what we actually had in mind when we wrote it.
It seems they tried to recreate Terraform's HCL language, but without Terraform behind. Still I don't see it's usage overlapping wit json/yaml/toml or whatever. Let's see 3 use cases: 1. Transport format: it doesn't seem suitable (if I need schema oriented stuff and validation why not using binary formats such as thrift,avro or protobuffers?) 2. app configuration: imho I still would go for something simple and execute logic in my application instead of adding an additional step in my build process for compiling and packaging 3. Build configuration: do i really need standardization?eg If I'm in the jvm ecosystem I use gradle with groovy or kts and there is one in a billion cases where I need to transfer this configuration to another stack. Yes it takes more mental energy to learn all the tools and languages in order to be a polyglot developer but there is not so much to do unless you don't want to invent a an ecosystem agnostic deps/build management system...and good luck with that!
This looks very much like the next log4j vulnerability waiting to happen. I'm always surprised how simple things like logging or configuring can become so overengineered. Also validating configuration options in the config rather than at it's use site strikes me as similar to validating user-submitted data only on the browser side and not the server side... it just feels wrong.
So from my understanding, this is supposed to help checking out projects, where the default config is ommitted from the repository, but you still want a default config to be created on first run, like an ENV bootstrap ? Or what is this useful for ?
I'm all in for built-in declarative validation rules, but built-in programming will make it hard to maintain readability (you don't know the result until the file is executed / compiled). Still will give it a go, though
I don't understand why this matters. If you need enforcement or validation at the configuration file level you catch it at processing or generation. This does the same thing while also being another middleware you have to configure and maintain. Saying that its hard to maintain some code that generates or validates your configuration or that any other languages isn't made for that is a silly thing to say.
A solution in search of a problem...that doesn't exist. We REALLY need to snap out of this mindset where everything needs to have a framework, transpiler, linter, build tool etc. JSON, YAML et al is super simple already. There is no need for introducing an intermediary format to "compile" it to JSON or YAML. It just ads complexity without any benefit. It's not like you can make one PKL config and then move it around between different applications, since those applications would have different config options and naming conventions.
This is so awesome ! Currently I'm using json config file to validate and get autocomplete on my json files. And I do not have the best experience with it. Pkl could be a game changer !
Thats very much like Lua programming language. But no surprise, Lua come to live as a syntax for configuration files that slowly turned into a language. Both JSON and YAML are a horror to write as configuration language. No comments, and fragile on JSON (and so many missing features) and YAML is just terrible with identation and getting it right in the complicated cases (YAML is at least 2 magnitudes more complex then JSON with anchor and refrences and comments).
Of course a third party might do it, but it's not likely to get first-class support from Hashicorp since they defined their own config language in HCL. It *might* make Hashicorp listen to users more and address some of the issues with HCL, though.
It's far from JSON/YAML. Also we have HCL which kinda masks itself as something extra. I am very sceptical of this. Smells like Protobuf, why not use the damn Protobuf?
Apple does some really cool things they have many many smart people. I'm glad they let things out into the world occasionally in source and showcase their things. - Now the itunes end of the spectrum, which I also group xcode into, is a bunch of trash. One of the reasons I avoid iOS develpment is the number of crashes and weird things xcode does.
in addition to all of that, XCode also steals the spot for the default application for almost every plain text file format except .txt itself, meaning you keep accidentally opening it.
Make the XCode vid. Every now and then I'm forced into it for some swift I have to deal with, and it's just the worst of the worst. So I think "NP, I'll just recode this app on Linux in a different language, and compile it on Mac." All is well until it comes time to sign the app with the Apple Dev key. Then, the nightmare begins anew.
Well, both. There's the json/yaml/whatever generators in the CLI itself. With those, you could only ever *write* PKL from now on and add a pkl step to your build process which translates your pkl config your desired format. There's also the interpreter/compiler implementation for different languages, so you could also load pkl files directly from through one of the supported languages (Go, Java, Kotlin, Swift) without the intermediate step to json/yaml/...
Honestly, I've already seen all of this before. There's a language much smaller called Nickel, same concept but it's based on FP (perfect for config) and it's already past 1.0.0.
Being a big fan of comptime in Zig, this will work beautifully. Types in more complex use cases are in desperate need of logic that can be resolved during the compilation of a particular program.
I thought this would be a minimal language that would extend json by a bit. So badically json with variables, for loops, comments, and a bit of extra logic. But still be simple enough to be easily embeddable (So you could "compile it" from any language by using a library). But this is basically terraform. If I ever need to generate JSON, I will just use some simple python script. Why learn a new thing when there's already an easy solution around the block?
Don't think kotlin support is mainly about android. Kotlin is used to build ios apps and apps across the Apple eco system. Also it's just a better java and it's able to interop with java so it seems like low hanging fruit though if it's true multi platform kotlin it'll be a bit more that java -> kotlin. Happy to see Go support as a first class supported language btw!
I'm not sure I understand the value of this. If you need to go from one language to another just write a compiler from one to the other. Why invent some new bespoke programming language just for configuration files? Your application should be validating your config anyway.
00s - use xml 10s - use json and... xml. for legacy reason 20s - use yaml and json and xml.... yes, still 30s - pkl! now we have pkl, yaml, json and... xml. yes you WILL
Years ahead: > a hefty chonk of industry now indulges Pkl`es in The Pantry Papple: > Oy, dearest fellas, we've been compelled to announce changes to licensing. Products with 100+ users shall now be subject to billing plans for them Pkl`s and are required to allow full telemetry & analytics on all yo' devices... ee and y'all have to use Siri
I've made a bunch of Python tools that all use YAML for config and despite anchors and my own hack for including files, DRY is not straightforward. I'd happily have a bunch of pkl files for my config if there was a way of getting the output into a Python dictionary.
JSON-Killer? JSON is mostly used for serialization. It Pros are a simple spec, human-readability and small data sizes. Pickle is just useful for configuration so it will not have much effect on JSON at all
When i heard about pkl i was not interested thinking we already have enough tools, but the features shown here have some features. I can imagine using this to share a configuration between a frontend js and a backend rust/php/c application.
How does pkl solve validation? If you write the checking condition into the config file, someone can just change the condition together with changing the config. It has to be validated in the application itself. So you could just use JSON Schema to validate a JSON config and that would work better, as the config itself is smaller and you don't have to implement validation twice and it's already supported by IDEs. I can imagine it for infrastructure as code but for example Terraform already has a language for it, called HCL. Maybe pkl is better than HCL. It looks to me not like a replacement for JSON but a programming language to generate JSON. Similar to CDKTF, where you write for example TypeScript code to generate a JSON to execute with Terraform. There Pkl could help.
I went over the source code of Pkl and although it support non-string keys in mappings (i.e. more like msgpack than JSON), it looks like very much it only support a subset of YAML 1.1. Since the YAML 1.2 has been out since 2009, that might have to do with the state of YAML parsers/dumpers in the Java/Kotlin, world and not necessarily a conscious choice by the developers. That unfortunately makes it only a potential replacement for a subset of YAML supporting applications, and also not a potential replacement for Python's pickle format.
I don't really get the hype. Most IDEs will tell you whether your JSON/YAML, .. is correct or not while editing the file. How can you make mistakes in there in 2024 is beyond me. So now you introduce a middleman to create your config. Another dependency.. And the value check.. in the actual code you don't know the source of your config. So you have to make your code robust anyway. So the check is useless or even bad IMHO.
What’s wrong with JSON? Is this another “use GraphQL” developer synopsis? Backend should handle validation, not the communication language stop inventing problems where there are none. If Apple would handle JSON properly they wouldn’t have a problem but they want to over engineer a “solution” instead of taking the time to understand the existing solutions.
I like the idea of a more powerful config lang - but it feels badly designed... yet another. Bad bad: * same file-extension for types and data * 6m38s the "Database" is not filled in fully ("port" is missing), but it's still a "Database" - i.e. fields don't need to be filled in - and this is sadly not expressed in types * "amend" is a badly chosen keyword... * reversing the dependency between programming-languages and config-languages * feels bloated Tradeoff: * feels like there is a lot of complexity in the language - so it's a big tradeoff vs a simple config language; now you need to learn another (almost?) turing complete language
I've been using Dhall for the last 5 or 6 years, I honestly think the only reason it hasn't caught on is it came from a functional programming background.
They open-sourced it because they want it to be a standard
because of 'Mother Nature"
I mean yeah it would be insane to keep this kind of thing proprietary no?
@@lmao4982you'd be surprised
Probably because they want people to freely maintain it.
I hate corporations abusing open source, but putting a big price to the end user.
Open source it's great when end users benefit from it. If open source is hidden under 20 meters of proprietary garbage, why is it any different then unpaid labor?
@@jhuglen whats wrong with it
The fact that Pickle and .pkl are already the name and extension for a common existing file format is driving me insane.
No one should use a file extension as identifier.
The fact that pickle ball makes such an annoying popping sound is driving me insane.
@@ck-dl4to NTFS had streams and that failed because people hate Metadata inside the file
Metadata goes in the file system, the name is Metadata, extension and file type also is
@@monad_tcp NTFS probably had streams because MacOS had resource files.
Swift was already a programming language before Apple release theirs
as a person who uses python pickle files every day i find this naming choice very annoying
Literally thought the same thing (but I’ve only used the library like once)
PYTHONISTA: REEEEEEEEEEEEEEEEEE
Youre supposed to name those as ".dat" files
I found it funny because usually if I wanted to pickle something, there was a better solution assuming I wanted my project to be scalable in some way.
And to be fair, you're going to choose one or the other, and as far as I know there's no external programs that open pickle files directly so you'll just be opening Apple's .pkl with a text editor and not touching pickles directly anyways.
You should probably stop using the security nightmare that is python pickle.
13:17 "Imagine if your JSON autocompleted and gave you errors when you were editing it"
You don't even have to imagine, it's already a thing with JSON Schema.
He mustn’t have edited a package.json in a while.
Within the first 3 mins of this video, I was already screaming JSON Schema. It follows DRY principles, has validation, is standardized, can be transpiled to POCO code in various languages. And JSON Schema files can also be referenced in an OpenAPI/Swagger spec to generate code for entire API endpoints.
But sure, Apple, do your own thing. Just like they are trying to build the next standard of podcasting when we already have a well-developed Podcasting 2.0 standard.
yep and it's supported natively by vscode
Typical theo
But it doesn't have for-loopsd!!@#!@#
I used to Pickle my Python back in the day.
Mmm Pickled python.
My mom used to as well
@@vikingthedudeYour mom used to pickle his python?
I still pickle my python. pkl is a well-known file extension for this. WTF
You can tell they want folks to use it because they also released a neovim plugin and aren't just catering to VScode users
Why does the EU live in your head rent-free?@@jhuglen
@@jhuglen Ah okay, I thought you had some weird hate-boner for the EU 😅
the neovim plugin is crap though
the smartest thing a new standard can do is make it easy to incrementally migrate, and it seems they are doing that
I love that the example password they used was "hunter2" lol
What was the password? All I see is *******.
I work at apple, i joined when it wasn’t open source and i was very skeptical about PCL ( internal it’s called PCL instead of PKL) but it does solve a lot of problems and the IDE integration is great. It has completely replaced helm in our team, it’s much better. I hope eventually helm charts will also be published in PKL.
if only they wouldve still call it PCL here, as there is quite a confusion in the python community haha
Someone's writing Doom in that
the funny thing is is that you're probably correct
"Pickle" sounds like "Pickel" which is German for "Pimple". Can't wait to hear my coworkers say "Create a pimple file for this project!". For that reason, I'm out 😆
I feel bad for people that have to now use this and the pickle module for file saving in python programs
I feel bad for people that have to use python.
Yeah fuck me
@@catalystcorpi feel bad for people
@@X-3KI feel bad
@@gh0stcloud499I feel
My first thought was it sounds just more complicated to use
@@jhuglen You really need to take a nap or some shit man. It's either extreme sleep deprivation, an absurd amount of alcohol, or you're doped the fuck up on psychedelics. Either way, you need a break
That's my second and third thought as well. No, wait, the third is overengineered.
Classes, functions, loops and annotations; surely they did not reinvent C# or Java?!
So to prevent using, say, groovy to do this, we now need pkl. That's just replacing 💩 with new 💩.
All this smells too much like XML with xml schema. But a bit better, because XML is a massive 💩🙃
There's another configuration language I like which is Dhall. For those who love Haskell, Rust and etc.
Unfortunately it seems only the Haskell bindings are maintained and non of the other languages.
I'm afraid that someone is going to craft some overly complex config with this syntax, becoming hard to understand and edit by others
I dont want logic in my config files, jesus christ I cant find this appealing at all.
Really i prefer to validate my jsonf config file in my code, i dont like this and i agree with you, whats with this trend of overcomplicating things....omg, for example in c# i could use a library like fluenvalidation an validate rules for my json's structure with rules like "port" is an int for example .... not needing to define a new language for that 🤣🤣
this, just writing the parser for this was probably some intern's whole summer and it only made the problem worse. JSON is from 2001 and it's not impressive to be slightly better than one part of it 20 years later.
I would love not to have to write any more validation code along the main code...
@@duartecunhaleao but consider that what is 'valid' may change from consumer or other factors and I doubt you are going to skip server/app side validations anyways and just leave it to this config, so you will end up doubling the validations. Also validation should be close to the app code im reading/writing as it is crucial.
Seriously. And if you are creating long config files with a lot of repetition just write a script to generate them.
Cool idea, but I'm having a hard time understanding the actual use case. I have never found myself needing a language agnostic config,
Both JSON and YAML have schema files which solves auto complete.
When you work with environments which practically live on configurations and a mistake can take down a fleet of services, this is _very_ useful.
About the IDE autocompletion 13:30, you do have json-schema.
@@jhuglen Wtf are you on about
@@jhuglenthe easiest comments to delete are the comments that never get made 🙏
@@jhuglenyou need to get off the internet
It’s time consuming to write, even if tools can help it’s full of boilerplate
Regex makes this all the more cursed. Now you can have a string format language inside of a data format language which can now be directly processed inside of your application's language, which means you have a language in a language in a language. I am absolutely digging this! 😂
Strictly speaking, RegEx is not a language, it is a pattern matching syntax.
What would a better alternative have been? Invent yet another string pattern matching syntax for Pkl?
@@mortenhattesenIt was (basically) a tongue-in-cheek comment.
It's basically the SCSS/SASS of config. Slick.
@@jhuglen hey can you stop spamming replies with this nonsense…
You are conflating two completely different things… Apple is forced by the eu to conform to certain standards that the eu has set, like using USB-C ports, but that doesn’t mean that the eu has “forced” them to make a config language they developed open source…
Like.. I really don’t know what you mean by “eu forced them” or “only in eu” here
I'm guessing you are 14 @@jhuglen
@@SwatejTech I wan't to know what he said ):
Actually, it's mostly HOCON.
Apple have a longer history of open source than Microsoft 😂😂 look up Darwin
I would rather them put thos energy into fixing the crashing bug in Xcode. Or maybe decoupling that IDE and compiler from MacOS versions so you can work on old apps without having to switch to old Macs with old MacOS versions.
lol, apple dev will always be somewhat cursed. Its what they chose when they decided to be super proprietary.
>old (anyhting)
>Apple
There is no backwards compatibility. There is no tolerance. You will work with the newest version, whether or not it makes sense.
You do realise Apple has more than 5 engineers and not all of them can meaningfully work on xcode, right?
does Apple even use XCode internally?
Sooo... They didn't know Nix, Nickel, Dhall, CUE, Jsonnet or HCL existed and therefore had to create their own thing? :/ It doesn't even look that good tbh. But yeah, impressive that Apple open sources something. That doesn't happen very often.
What browser did you use to make your comment?
@@jhuglenWhy on Earth are you constantly talking about the EU in every single comment?? What about any of this has anything to do with the EU????
@@jhuglenbro you’re drunk get off RUclips 💀
@@jhuglen
The EU just said you need user consent before you store data on their PC for reasons other than purely functional.
The Industry could have just followed the Do Not Track setting, but they want your data. Not the EU's fault that sites are evil.
Cuelang is still rough but the real deal. I'm trying to understand it better and contribute.
Dude this isn't as big of a problem in JS land. For JSON, we have schemas. For JavaScript and TypeScript, most packages come with a defineConfig out of the box, and if they don't, rest assured somebody has already published an NPM package for that purpose.
i never liked json until the pretentious french pronunciation
And the name is…
Turing complete in data format? Once again proving the only thing human learnt from history is that we learnt nothing from history.
They thankfully realised that the only way to have it adopted is to not only open source it but provide extensions to major editors, even VS Code. It's a good call, if they tried to make something proprietary, it would die painfully.
Pkl seems cool, but it smells of something that will be infamous for quirks and hard to make parsers like YAML. Time will tell I guess, I do like it and hope it catches on and ends up being good.
How would you compare this to Cue? Seems like they are solving the same problems
Yes, definitely! cue seems more pure and pkl more eng oriented.
They clearly share underlying abstraction.
I was thinking the same thing
Cue looks more powerful to me. The built in scripting engine in Cue is brilliant.
@@DryBones111 Hopefully no security holes.
chatter getting worked up about "version conflicts in config files": that's literally just a thing. The config format (or parts of it) may change over time after all, and it's important to keep track of that. It's great if Pkl can encode these existing problems and provide editor support for solving them... tho I wonder what form that'll take in practice, if and how different versions of a config format might be supported at the same time.
There's a difference between changing config files and tracking configuration versions so you can load data from older formats properly.
Honey, I shrunk the JSON!
Don’t worry, you have a great personality ❤
Did you end up with YAML?
When I saw a configuration language that is "a blend between a static language and a general-purpose programming language" I immediately thought of Nix, a language with similar ideas created for a similar purpose. Nix doesn't seem to do very well outside Nix and NixOS ecosystems though, and Pkl does seem easier to grasp.
Totally agreed - for my NixOS system that I have been using for almost 4 years now I am happy with the subset of the Nix language that I need to know, but even then it sometimes still is hard for me to understand the syntax. And for programmer that is not used to it I think it is harder to fight with some of the constraints that you will run into when using nix in a very dynamic ecosystem: in the company I work for we are using it e.g. for building some JavaScript stuff and just the amount of work it takes for _some_ of the dependencies to be packaged is just insane (but to be honest, so is what those dependencies are doing on installation...). So yes - I really love NixOS, but I personally am sometimes struggling a bit with the nix language (yes - because I don't use it (or something similar) that often)
@@miallo just learn FP .. here's a hint: you can do everything with foldl'
Pkl feels like Typescript meets SASS
I was about to say something similar.
Very true.
I'm going to keep using JSON, avoid YAML, never use XML on principal and now avoid using Pkl. Sounds good!
Why they need validation in a config file? My program can read the file and tell the user what is wrong. I don't need to learn a new scripting language for that.
And if you config file gets too big I want to use a real programming language to create it anyway. Plus source control.
All the Python folks are hissing about this (don’t blame ‘em, they’ve been using “pickle” for serialization for ages).
Anyway - I wonder if at Apple, all their Kubernetes cluster manifests are written in Pkl files. Hmm… that’d be interesting to look at!
Just use JS. extend JSON with JS that’s the sane way to do it. I didn’t like this pkl thing at all.
This concept has already been executed in the form of Dhall and Nickel. Nice to see another competitor, but I’ll stick with Dhall.
Had not heard of DHall or Nickel. Just found their websites and notice that while DHall has a VS Code plug-in, they have no support for JetBrains IDEs. So for that reason alone Pkl is more attractive to me, since I'm spend most of my days in GoLand.
Yes .properties are still being used especially in default spring boot apps
Can't blame him. He lives in a frontend bubble.
you can use yaml configs which are more readable for larger configs
@shubitoxX I know I just wished my department used YAML more often 😂
So C macros for config files? something like Cmake? This is just another syntax to add to the collection I have to use once every few weeks. Between all these scripting languages, config formats, CLIs, programming languages, etc we are expected to know is nearing 100+.
you can actually use C macros in any languages, but nobody does it because it would confuse newbies who have no idea what a preprocessor is
EDIT: also your IDE would complain about syntax errors lol
Definitely not like CMake. Thankfully.
Xcode is a shit show? Compare to what, exactly? Hopefully not Android Studio. I would like to see that video.
So they recreated DHALL?
So, they created Cascading Configuration Language; they should have named it CCL.
Given how maintainable the seemed-like-a-good-idea-at-the-time CSS turned out to be, I am not so sure that we should consider them creating a cascading configuration language to be a good thing... 🤷♂️
#jmtcw
Am I the only one that thinks this would be creating more work and costing more time than it saves? It just seems awfully redundant. Maybe it's just because of the nature of what my projects usually are...
This is very very cursed, could not expect less from Apple
I swear people undervalue the importance of ease of writing a parser. JSON was designed to be easy to parse; this obviously is not
I hate languages like this because they have weird syntax and are gimped in some stupid way. If your config situation starts calling for variables, logic, data structures, type checking, loops, a compile step, and a fucking package manager... you are writing code. PLEASE just use a general purpose programming language at that point. This is how we end up with MSBuild XML
No, thanks. This is like the XKCD comic about the new standard. JSON is mostly fine. JSON needs improvements but it doesn't need to be replaced. I regret clicking on this video.
Nope. This is the last thing the industry needs. Sensible consumers avoid their overpriced products, and they should also never touch an apple technology that tries to get into our workflow. "FOSS" or not.
No more corporate closed source proprietary. Snap out of it people, development isn't fashion.
As a Typescript developer i don't see much value in this, because a pkl file have roughly the same lines of code of a regular js/ts file used for configuration, but using js/ts doesn't need to install additional binaries or dependencies.
However i can see some potential for more complex languages like Go/Rust/Java/etc. that are not suited for small "scripts" since they take in account stuff that you don't care when creating a configuration file such as pointers, packages, namespaces, classes, the borrow checker, constructors, errors handling.
> but using js/ts doesn't need to install additional binaries or dependencies
Huh? What world are you living in where JS and TS doesn't require binaries or dependencies?
@@dealloc Computer has already NodeJS installed. So you don't need to install anything extra.
@@recepciftci2642 What computer? No computer comes with NodeJS preinstalled. You may have Docker images, but then it makes his initial point moot.
Plus you'd still need to add TSC compiler as a dependency.
That is besides the point, it's comparing apples to oranges.
@@dealloc you don't need to add TSC to a TS project, because it's already been added. Use TS configs for TS projects, PHP for PHP projects, you get it
@@dealloc I will help you understand the comment. The comment did not mean that JS and TS doesnt require binaries / dependencies to be installed, the commentor was talking about simply using JS/TS files as a configuration file, thus not having to install any other binaries related to configuration management tools. Sometimes its okay to assume things and not take everything literal, especially in a world in which english is a secondary or tertiary language for many people. Perfect grammar is something alot of us wish we'd have. Sometimes we slip up, and the meaning of a sentence might differ from what we actually had in mind when we wrote it.
It seems they tried to recreate Terraform's HCL language, but without Terraform behind. Still I don't see it's usage overlapping wit json/yaml/toml or whatever. Let's see 3 use cases:
1. Transport format: it doesn't seem suitable (if I need schema oriented stuff and validation why not using binary formats such as thrift,avro or protobuffers?)
2. app configuration: imho I still would go for something simple and execute logic in my application instead of adding an additional step in my build process for compiling and packaging
3. Build configuration: do i really need standardization?eg If I'm in the jvm ecosystem I use gradle with groovy or kts and there is one in a billion cases where I need to transfer this configuration to another stack. Yes it takes more mental energy to learn all the tools and languages in order to be a polyglot developer but there is not so much to do unless you don't want to invent a an ecosystem agnostic deps/build management system...and good luck with that!
This looks very much like the next log4j vulnerability waiting to happen. I'm always surprised how simple things like logging or configuring can become so overengineered. Also validating configuration options in the config rather than at it's use site strikes me as similar to validating user-submitted data only on the browser side and not the server side... it just feels wrong.
"What if I told you that alternative was by Apple"
Wow. You lost me within the first 15 seconds.
So from my understanding, this is supposed to help checking out projects, where the default config is ommitted from the repository, but you still want a default config to be created on first run, like an ENV bootstrap ?
Or what is this useful for ?
reading an article while recording yourself is soooo creative, original and value adding....
I'm all in for built-in declarative validation rules, but built-in programming will make it hard to maintain readability (you don't know the result until the file is executed / compiled). Still will give it a go, though
I don't understand why this matters. If you need enforcement or validation at the configuration file level you catch it at processing or generation.
This does the same thing while also being another middleware you have to configure and maintain. Saying that its hard to maintain some code that generates or validates your configuration or that any other languages isn't made for that is a silly thing to say.
People who use Yaml are beyond saving…
Every year you present two vscode killers and three json replacements
spring boot integration 😲
A solution in search of a problem...that doesn't exist. We REALLY need to snap out of this mindset where everything needs to have a framework, transpiler, linter, build tool etc. JSON, YAML et al is super simple already. There is no need for introducing an intermediary format to "compile" it to JSON or YAML. It just ads complexity without any benefit. It's not like you can make one PKL config and then move it around between different applications, since those applications would have different config options and naming conventions.
This is so awesome !
Currently I'm using json config file to validate and get autocomplete on my json files. And I do not have the best experience with it.
Pkl could be a game changer !
Thats very much like Lua programming language. But no surprise, Lua come to live as a syntax for configuration files that slowly turned into a language.
Both JSON and YAML are a horror to write as configuration language. No comments, and fragile on JSON (and so many missing features) and YAML is just terrible with identation and getting it right in the complicated cases (YAML is at least 2 magnitudes more complex then JSON with anchor and refrences and comments).
I can't wait to see this for Terraform
Of course a third party might do it, but it's not likely to get first-class support from Hashicorp since they defined their own config language in HCL.
It *might* make Hashicorp listen to users more and address some of the issues with HCL, though.
I agree with your point of view！！！
Have you tried cdktf?
It's far from JSON/YAML. Also we have HCL which kinda masks itself as something extra. I am very sceptical of this. Smells like Protobuf, why not use the damn Protobuf?
oh and I forgot XML and XSD (their Properties Plist nonsense). And TOML, INI, and probably half a dozen other configuration languages.
Apple does some really cool things they have many many smart people. I'm glad they let things out into the world occasionally in source and showcase their things.
- Now the itunes end of the spectrum, which I also group xcode into, is a bunch of trash. One of the reasons I avoid iOS develpment is the number of crashes and weird things xcode does.
in addition to all of that, XCode also
steals the spot for the default application for almost every plain text file format except .txt itself, meaning you keep accidentally opening it.
If Microsoft has thought us anything it’s that any company can go open source.
Make the XCode vid. Every now and then I'm forced into it for some swift I have to deal with, and it's just the worst of the worst. So I think "NP, I'll just recode this app on Linux in a different language, and compile it on Mac." All is well until it comes time to sign the app with the Apple Dev key. Then, the nightmare begins anew.
Look cuelang, its been around for long and been more robust !!
If they keep extending it this way, they'll eventually end up with full blown JavaScript.
So it doesn't replace or "kill" anything, it just makes making those things more usable? I don't think I'm understanding it right
Clickbait
Well, both. There's the json/yaml/whatever generators in the CLI itself. With those, you could only ever *write* PKL from now on and add a pkl step to your build process which translates your pkl config your desired format. There's also the interpreter/compiler implementation for different languages, so you could also load pkl files directly from through one of the supported languages (Go, Java, Kotlin, Swift) without the intermediate step to json/yaml/...
@@felixw841 But whats wrong with json schema?
So they essentially made protobuf for config files
Python’s pickle library: am I a joke to you?
Honestly, I've already seen all of this before. There's a language much smaller called Nickel, same concept but it's based on FP (perfect for config) and it's already past 1.0.0.
1:26, Apple has an official Swift LSP for VSCode btw
Being a big fan of comptime in Zig, this will work beautifully. Types in more complex use cases are in desperate need of logic that can be resolved during the compilation of a particular program.
I thought this would be a minimal language that would extend json by a bit. So badically json with variables, for loops, comments, and a bit of extra logic. But still be simple enough to be easily embeddable (So you could "compile it" from any language by using a library). But this is basically terraform.
If I ever need to generate JSON, I will just use some simple python script. Why learn a new thing when there's already an easy solution around the block?
Don't think kotlin support is mainly about android. Kotlin is used to build ios apps and apps across the Apple eco system. Also it's just a better java and it's able to interop with java so it seems like low hanging fruit though if it's true multi platform kotlin it'll be a bit more that java -> kotlin.
Happy to see Go support as a first class supported language btw!
Let's make inefficient configs also confusing.
I'm pkl Rick
I don’t like that it has the same name as pythons serialisation format.
some of this was the informal inspiration to lua and why it ended being a programming language... it started out as a configuration file reader...
Apple reinventing Nix was unexpected to say the least.
I'm not sure I understand the value of this. If you need to go from one language to another just write a compiler from one to the other. Why invent some new bespoke programming language just for configuration files? Your application should be validating your config anyway.
It's funny because the competitor cuelang has this philosophy. Write cuelang or import from GO or protobuf, and export/compile to anything you want.
00s - use xml
10s - use json and... xml. for legacy reason
20s - use yaml and json and xml.... yes, still
30s - pkl! now we have pkl, yaml, json and... xml. yes you WILL
Is it a less powerful nix?
I will wait till openai, trains gtp on pickel.
Years ahead:
> a hefty chonk of industry now indulges Pkl`es in The Pantry
Papple:
> Oy, dearest fellas, we've been compelled to announce changes to licensing. Products with 100+ users shall now be subject to billing plans for them Pkl`s and are required to allow full telemetry & analytics on all yo' devices... ee and y'all have to use Siri
I've made a bunch of Python tools that all use YAML for config and despite anchors and my own hack for including files, DRY is not straightforward. I'd happily have a bunch of pkl files for my config if there was a way of getting the output into a Python dictionary.
JSON-Killer? JSON is mostly used for serialization. It Pros are a simple spec, human-readability and small data sizes.
Pickle is just useful for configuration so it will not have much effect on JSON at all
When i heard about pkl i was not interested thinking we already have enough tools, but the features shown here have some features. I can imagine using this to share a configuration between a frontend js and a backend rust/php/c application.
Now: Let's use pkl for a standard to get calendar entries done properly on each system. Could have the power to do so. Who's on board?
How does pkl solve validation? If you write the checking condition into the config file, someone can just change the condition together with changing the config. It has to be validated in the application itself. So you could just use JSON Schema to validate a JSON config and that would work better, as the config itself is smaller and you don't have to implement validation twice and it's already supported by IDEs. I can imagine it for infrastructure as code but for example Terraform already has a language for it, called HCL. Maybe pkl is better than HCL. It looks to me not like a replacement for JSON but a programming language to generate JSON. Similar to CDKTF, where you write for example TypeScript code to generate a JSON to execute with Terraform. There Pkl could help.
I went over the source code of Pkl and although it support non-string keys in mappings (i.e. more like msgpack than JSON), it looks like very much it only support a subset of YAML 1.1. Since the YAML 1.2 has been out since 2009, that might have to do with the state of YAML parsers/dumpers in the Java/Kotlin, world and not necessarily a conscious choice by the developers. That unfortunately makes it only a potential replacement for a subset of YAML supporting applications, and also not a potential replacement for Python's pickle format.
8:20 they added regex AS A STRING, so you have to escape every backslash 😂
hunter2 as the example password is a funny reference
I don't really get the hype. Most IDEs will tell you whether your JSON/YAML, .. is correct or not while editing the file. How can you make mistakes in there in 2024 is beyond me.
So now you introduce a middleman to create your config. Another dependency..
And the value check.. in the actual code you don't know the source of your config. So you have to make your code robust anyway. So the check is useless or even bad IMHO.
What’s wrong with JSON? Is this another “use GraphQL” developer synopsis? Backend should handle validation, not the communication language stop inventing problems where there are none. If Apple would handle JSON properly they wouldn’t have a problem but they want to over engineer a “solution” instead of taking the time to understand the existing solutions.
I like the idea of a more powerful config lang - but it feels badly designed... yet another. Bad bad:
* same file-extension for types and data
* 6m38s the "Database" is not filled in fully ("port" is missing), but it's still a "Database" - i.e. fields don't need to be filled in - and this is sadly not expressed in types
* "amend" is a badly chosen keyword...
* reversing the dependency between programming-languages and config-languages
* feels bloated
Tradeoff:
* feels like there is a lot of complexity in the language - so it's a big tradeoff vs a simple config language; now you need to learn another (almost?) turing complete language
I've been using Dhall for the last 5 or 6 years, I honestly think the only reason it hasn't caught on is it came from a functional programming background.