Very cool!

You might want to consider also publishing a schema for it too, as a Pkl package. The package can simply be published as a GitHub release (see details in this post here: https://github.com/apple/pkl/discussions/85#discussioncommen...)

Also, despite being written in Java, Pkl is distributed as a native executable for macOS and Linux (Windows coming soon).

But yeah, you do need the executable installed on your system in order for our pkl-go bindings to work.

Needing the pkl CLI adds a runtime dependency I'd rather not have.

Is there any way to use pkl from Go without needing to shell out? Maybe Go library that calls a wasm blob or something?

Pkl is newly open sourced, but it not new. It's been used for years at Apple, and has been battle tested internally.

I'd actually say that our tooling in some ways is more mature. For example, I think our IDE experience (at least in JetBrains editors) is the best out there.

There is no trust in the words “we tested this internally.”

Apple employees can rate it as an old project among themselves, while it is more convenient for everyone else to rate the product from the moment of publication.

Hey, I recognize this name :D

Yeah, it's been a long time coming, and it feels great to finally get this out in open source.

FDB is open source too, BTW: https://github.com/apple/foundationdb

At some point, we'll publish more documentation about this, including instructions for how to build your own language binding.

And, it's only a sub-process right now, but we plan on also providing a C library as another way to bind to Pkl.

But if you want to learn more about how this works, feel free to connect with us on GitHub! https://github.com/apple/pkl/discussions

There's no "walled garden" here. We want Pkl to be useful for many developers, for a variety of purposes. Hopefully that's clear enough with Java, Kotlin, and Go being amongst the various supported language bindings. We also already support Linux, and plan on supporting Windows.

It's also open sourced under the Apache 2.0 license, which grants you the right to distribute and modify it.

Cheers

I appreciate you having good intentions. I don't mean to be disrespectful.

This however does not change my position that we have more than enough scripting languages focused on string operations, and don't need another language. And especially not a bloated one that itself depends on huge frameworks. If the same task can be solved using a 76KB standard Unix tool, creating a custom language with a huge bloated runtime simply can not be justified. It's bringing a sledgehammer for a task where a swiss pocket knife would be appropriate.

And my position also stands that it would make far more sense to finally agree on a config file standard format, with native parsers existing in every major programming language, so people stop re-inventing the wheel again and again and again, with the wheel becoming heavier and bulkier and less round every time.

> And my position also stands that it would make far more sense to finally agree on a config file standard format

It would also make far more sense for humans to agree on most things and work towards a common goal that benefitted us all, but that’s just as much of a pipe dream.

Proposing something that will never happen is not a practical solution.

https://xkcd.com/927/

communism immediately comes to mind. beautiful idea, but also the idea with the largest body count in the human history.

I/O can be sandboxed via flags.

For example, see these CLI flags: https://pkl-lang.org/main/current/pkl-cli/index.html#common-...

And when using the different language bindings, you can specify sandboxing options directly in that library.

How many people will run a malicious config at least once without the flags? At some point it becomes a numbers game.

I think this is a reasonable approach if you only have one stack, and don't have a lot of config. If you have one stack, you can put all the validation, types, and everything else in your runtime application, and then you don't need to learn new languages, and everything works.

This becomes a lot more painful if your work is more polyglot. If you need to define config that needs to be shared between different applications, but they're written in different languages, you'll have a much harder time. Also, say, if you need to deploy your applications to Kubernetes, and your Kubernetes specification needs to provide config files to your application, then you'll still end up in a situation where your statically typed programming language won't help. That is where something like Pkl becomes really helpful, because you have just one place to manage all that complexity--right in Pkl itself.

> A problem space I'm familiar with is having a bunch of Terraform or Cloudformation configuration you want to share/repeat in multiple projects. Doing-so can get hairy quickly, as the path of least resistance is to copy-paste a bunch of config you barely understand from some other project, and then perform trial-and-error surgery to find and change a couple of lines to suit your project.

Yes, Pkl is meant to solve this problem. It's a single place for you to configure all your targets. Within the same codebase, you can generate static configuration, and also import the same Pkl source files into a runtime application, so you don't have to copy/paste things around.

Thank you so much for the explanation!

I see much more clearly how something like this could be extremely useful.

Python isn't oriented around defining and validating data.

For example, something like: "this number is be between 1 and 10" means you have to come up with a novel way to add validation, because it isn't built into the language.

Also, Pkl is meant to be usable everywhere. General purpose languages tend to be tied to their own ecosystem--imagine telling a Go developer that they need to install Python, set up virtualenv, and run pip install so they can configure their application. We'd like Pkl to be a simple tool that can be brought anywhere, and easily integrated into any system.

> For example, something like: "this number is be between 1 and 10" means you have to come up with a novel way to add validation, because it isn't built into the language.

No need for a novel mechanism - there are plenty of available solutions to add validation to python

> imagine telling a Go developer that they need to install Python

Pkl doesn't come preinstalled on machines - so you'll have to install it as well

> set up virtualenv, and run pip install so they can configure their application

This is the real friction point, but is it a bigger friction point than having to adopt yet another DSL?

> This is the real friction point, but is it a bigger friction point than having to adopt yet another DSL?

Yesterday, I created a virtualenv, then ran `pip install`, only to see it fail. I found out that even `pip --version` was failing. I discovered that running `python -m ensurepip --upgrade` would fix pip. It did fix pip, but `pip install` still didn't work properly. I figured out that pip was reporting a different version of python than the one virtualenv is using. Running `python -m pip install --upgrade pip` upgraded pip, which should have been accomplished with the previous ensurepip command. Finally, everything was working properly.

I experienced these problems after years of experience in python. To answer the question. Yes, it's worth adopting yet another DSL than using python.

Did you activate the virtual environment?

For all the flak python gets, dependency setup is pretty simple if you're not flailing around aimlessly

  python3.12 -m venv --copies --clear --upgrade-deps ".venv"
  source ".venv/bin/activate"
  python -m pip install --upgrade pip setuptools wheel
  python -m pip install --editable .

Yes, I had activated the virtual environment. Thanks for the guide. It works without problems. I had used `virtualenv venv -p /usr/local/bin/python3.12` in my setup. Yours seems to be a better way.

That right there is the main problem with python dependency management - too many damn ways to do the same thing.

And to think "There should be one-- and preferably only one --obvious way to do it." is in the Zen of Python...

assert x >= 1 and x <= 10, "x is out of the allowed range"

What novel way to add validation in python?

This made me realize that Go actually succeeds at being more pythonic than python.

I'm also incredibly high.

High or not, you're 100% correct.

Have a look at PEP 20 – The Zen of Python.

Python is actually horrible at following it, Go doing a much better job.

Pkl is a new language for describing configuration. It blends together the declarative nature of static formats like YAML or JSON, with the expressiveness, safety, and tooling of a general purpose programming language.