this post was submitted on 03 Feb 2024
36 points (97.4% liked)

Programming

17443 readers
187 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
top 19 comments
sorted by: hot top controversial new old
[–] [email protected] 5 points 9 months ago

cough::bro, do you even NIX?::cough

[–] [email protected] 11 points 9 months ago* (last edited 9 months ago)

This is a great project and I'm surprised by the tone of the response here. I think most folks are forgetting that most of the people dealing with configuration are not programmers by trade. They just need to setup a tool for their use case. To that end, the gap between the existing configuration paradigm and extending their software is practically insurmountable. This language bridges that gap in a robust and purpose built way and that is going to make a lot of people's lives and jobs easier.

Think about homeassistant and how much less fidly it'd be to get advanced functionality or interfaces if the gap between programming and configuration were closed? There is an absolute fuckton of enterprise and scientific software that will improve in the same way.

[–] [email protected] 7 points 9 months ago

This seems to have many similar ideas as Dhall Lang - https://dhall-lang.org/

[–] [email protected] 8 points 9 months ago

Vscode already supports linting yaml against a schema file. Once you start configuring your code with configuration-as-code, you’re just writing more code.

If I need to “generate” some insane config with miles of boilerplate, I would use js to build my json, which can be ported to just about anything. This would replace js in that process.

I’m not sold on the need for this.

Even with something like k8s, I’d reach for pulumi before I put another layer on top of yaml.

[–] [email protected] 13 points 9 months ago (1 children)

Disclaimer: I don’t yet understand why this is valuable.

I looked through the yaml example a bit. It looks pretty rough. This really makes familiar and readable yaml into much longer configuration. It’s much harder to read. First impression is a pass.

[–] [email protected] 3 points 9 months ago* (last edited 9 months ago)

The biggest advantage is IDE integration.

You can type port = 42 and instantly be told, right there as you edit the file, that you entered an invalid value (port has to be at least 4 digits). It will also flag prot = 4242 as invalid — catching the typo. That's a real advantage - just last week I took a server offline by making a human error in a config file. The server just didn't respond to network requests after the change was applied and it was part of a larger deployment... so it took time to find the mistake. Catching mistakes early is a good thing.

The second big advnatage is integrated documentation - for a lot of work you won't need to read the manual in a web browser. You can just jump into the config file, hover your mouse over something, and know how it works.

It has other strengths, but those are the big two. Probably the third is it's just a nice language to read and write (plenty of other options share that, but it's hardly universal).

I looked through the yaml example a bit. It looks pretty rough.

Some of those examples are unnecessarily complex to demonstrate rarely used features. I like this example better:

amends "service.pkl"

host = "example.org"
port = 4242

The only slightly ugly thing is the amends line, which defines a second config file that defines rules about how to properly configure this one. In that case it's a path to a file on disk, but it could also be a URL such as https://pkl.apache.org/virtualhost if apache were to switch to this format for VirtualHost config files. If you don't need to import rules for use case, it's an optional feature (though it is the main advantage pkl has over other alternatives).

As far as I know the only widely used config format with support for strict rules is XML, but XML is so complex that almost nobody can actually get IDE integration working. The rules are just too complex. Pkl is simple, these properties need to exist, they have these types (text, number, etc) and these restrictions (minimum 4 digits, etc).

[–] [email protected] 21 points 9 months ago* (last edited 9 months ago) (1 children)

I don't think configuration languages should be turing complete. At that point you're just writing an extension.

[–] [email protected] 2 points 9 months ago (1 children)

Unpopular opionion(?): this is why I hate Ansible

[–] [email protected] 2 points 9 months ago

Honestly what can be done with Ansible that isn't achievable with a shell script or two and a yaml file?

[–] [email protected] 4 points 9 months ago

This looks really interesting. Getting type safety and editor support to configuration may change quite a bit of how things are done. I don't know if it will gain traction, but if it does, it may really help bringing some long awaited structure to all those YAML files. There appears to be examples specifically for Kubernetes (https://github.com/apple/pkl-k8s-examples).

[–] [email protected] 8 points 9 months ago (2 children)

Was there anything particularly wrong with json schema? Aside from being a validator and not a “language”.

https://json-schema.org

[–] [email protected] 4 points 9 months ago* (last edited 9 months ago) (1 children)

Pkl is a hell of a lot easier to work with. Compare this pkl code:

host: String
port: UInt16(this > 1000)

To the equivalent in json:

{
  "$schema": "http://example.org/my-project/schema#",
  "type": "object",
  "properties": {
    "host": {
      "type": "string"
    },
    "port": {
      "type": "number",
      "minimum": 1000,
      "exclusiveMinimum": true
    }
  },
  "required": ["host", "port"]
}
[–] [email protected] 1 points 9 months ago
[–] [email protected] 3 points 9 months ago (1 children)

I just learned about Pkl, so take this with a grain of salt. JSON Schema and Pkl seem to have some overlap. But JSON schema is not specifically designed for handling configuration and Pkl supports other formats like YAML.

[–] [email protected] 4 points 9 months ago (2 children)

JSON schema supports YAML as well, no? That's because JSON and YAML are both essentially just different syntaxes for writing the same objects right?

[–] [email protected] 4 points 9 months ago (1 children)

It's the other way around. The YAML schema supports JSON because YAML was designed as a superset of JSON.

@Lynxtickler @canpolat

[–] [email protected] 1 points 9 months ago (1 children)

I get where you're coming from, but JSON Schema still absolutely is the framework that supports YAML files and not the other way around. I've been using JSON Schema pretty heavily lately to write schemas using YAML, for validating YAML.

[–] [email protected] 1 points 9 months ago

@Lynxtickler ahh, I misunderstood what you were referring to. Didn't realise you were talking about JSON Schema and not the JSON syntax itself.

[–] [email protected] 1 points 9 months ago

Possibly. My point is: despite having a common subset Pkl and JSON schema doesn't seem to be solving the same problems. But, I'm just learning about it, so I may just be wrong.