Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pkl, a Programming Language for Configuration

pkl-lang.org

Post reply on HN
Print view View original

331–340 of 598 posts

Re: Pkl, a Programming Language for Configuration

#331

Post by samatman »

hgs3 wrote: post #289
avianlyric wrote: post #268

Earlier quoted context omitted.

> For you a "date" type might mean ISO 8601, but for me it might mean RFC 3339 A generic date type doesn’t come with any specific string format. ISO 8601 and RFC 3339 are both ways of representing a date as a string. Which has little to do with Date as a type. There’s also perfectly good solutions to those problems. Use a type alias to create a date type backed by a string, with formatting constraints (such as a rege…

> ISO 8601 and RFC 3339 are both ways of representing a date as a string. Which has little to do with Date as a type. Tell that to the TOML authors [1]. It's good Pkl has string validation, but what if I don't want a string? What if I want my own literal datetime syntax, like TOML? The grammar for a configuration language could be made flexible enough to accept most anything as a value. In such a design the "string"…

This choice in TOML is a mixed bag. I would say it's substantially mitigated by the fact that strings must be quoted, so you don't have strings magically turning into datetimes if they look like a date. But it does add substantially complexity to an otherwise simple language.

The near-compatibility of ISO 8601 and RFC 3339 is a rich source of bugs, but that's hardly TOML's fault, and the standard is perfectly clear that the latter is used. TOML, like many configuration and data transport languages, is defined in terms of its syntax, so an abstract Date type doesn't make sense for it.

Providing a datetime format for TOML was probably the right decision, I think there are more people who complain about JSON lacking one than there are who complain about TOML having one.

Re: Pkl, a Programming Language for Configuration

#332

Post by whacked_new »

baq wrote: post #81
msoad wrote: post #32

JSONSchema covers a lot of various schema needs and YAML is something a lot of developers are comfortable with. I know both of those technologies are not popular here in HN but YAML type-checked and editor-autocomplete-enabled using JSONSchema is a solid choice for configurations in my opinion.

Jsonschema is still json and yaml is absolutely not comfortable to work with. It’s only enough for simple configs. As soon as you have the urge to use a template you should replace it with something else.

I use jsonnet for templating and transformation and jsonschema for validation. Very happy with this combination. One big reason is that there are lot of libraries and codegen tools to choose from once you have the JSON generation pipeline (including schema generation) down.

Re: Pkl, a Programming Language for Configuration

#333

Post by stockholm »

krajzeg wrote: post #109
grashalm wrote: post #79

Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. We have been working with Apple on this for a while, and I am quite happy that we can finally read the sources! https://github.com/oracle/graal/tree/master/truffle Disclaimer: graalvm dev here. Edit: typo

> ...GraalVM Truffle framework... Futurama Projections... I know it's partly on me for not knowing the domain, but I honestly suspected somebody is trying to make fun of me with some concentrated technobabble. Especially since I wouldn't expect the topic (configuration languages) to require complex mathematical machinery to work with. Now I have something interesting to dig into.

This comment is what PKL is going to be remembered for. Tbh I wouldn’t even have the courage to write the comment myself as the framework was coming from Apple.

Re: Pkl, a Programming Language for Configuration

#334

Post by whacked_new »

vaylian wrote: post #284
sph wrote: post #167

Earlier quoted context omitted.

I have been looking into alternatives to YAML templating, the Helm abomination, etc. and was utterly surprised how no one ever apparently has thought to create a configuration/templating system that's basically a fancy library on top of Scheme. I truly believe every company is still reinventing the wheel because of a lack of serious foundational knowledge in most engineers, so they are doomed to recreate subpar, shit…

> was utterly surprised how no one ever apparently has thought to create a configuration/templating system that's basically a fancy library on top of Scheme. There's Clojure's extensible data notation: https://github.com/edn-format/edn

edn + clojure was the most pleasant configuration system I've worked with, but I have never convinced anybody else to use it. Jsonnet on the other hand, people get productive in it pretty quickly. It's my default choice for all configuration now.

Re: Pkl, a Programming Language for Configuration

#335

Post by tadfisher »

chris_wot wrote: post #303
SOLAR_FIELDS wrote: post #216

Earlier quoted context omitted.

FWIW Graal is probably one of the most exciting technologies to come out of Oracle in a long time.

It came out of Oracle. Kids of death.

It's GPL-licensed, and it works. I'm happy they haven't Oracle-ized the JVM, and have been investing into great features that are available to everyone for free.

Re: Pkl, a Programming Language for Configuration

#336

Post by TwentyPosts »

rurban wrote: post #314
omoikane wrote: post #311

It seems like a truncated Pkl file can still be a syntactically valid file? This is a problem with TOML and YAML (but not JSON) where the language itself doesn't protect against truncations, and applications will need to add end-of-file markers or something similar in their config schema. I am not sure if Pkl has some built-in feature related to this sort of thing.

That's a feature, not a bug. Truncated files should not be accepted as valid

So you agree with them that it's a problem...?

Re: Pkl, a Programming Language for Configuration

#337

Post by jwoq9118 »

rockwotj wrote: post #282
p10jkle wrote: post #152

Earlier quoted context omitted.

For me, that's where all the power of the language comes from. It's like writing your config in Go or Python (which I think is also a great approach) except its designed from the ground up for this use case of config generation.

Ah just give me typescript, I do not need to learn a new thing for configuration languages and at the end of the day the output is compatible with JSON. Typescript has all the stuff I would want: types, first class json support, an ecosystem of libraries (if you want it, I would probably not for config generation). And the tooling is amazing. Does pkl have LSP, syntax highlighting in every editor, debugger or repl?

Agreed. If we're getting the point where you're saying "it's like writing your configuration in [insert Domain Specific Language Here]" then I'd prefer to simply use that language. I understand the point Pkl is making in that "configuration won't work across DSLs so here's one language for all of them" but I don't know that that's enough motivation for people to adopt it.

However, I haven't built anything cool like this so what do I know. I'm just procrastinating on the my personal project and browsing hacker news.

Re: Pkl, a Programming Language for Configuration

#338

Post by sesm »

whacked_new wrote: post #334
vaylian wrote: post #284

Earlier quoted context omitted.

> was utterly surprised how no one ever apparently has thought to create a configuration/templating system that's basically a fancy library on top of Scheme. There's Clojure's extensible data notation: https://github.com/edn-format/edn

edn + clojure was the most pleasant configuration system I've worked with, but I have never convinced anybody else to use it. Jsonnet on the other hand, people get productive in it pretty quickly. It's my default choice for all configuration now.

I wonder, what would happen if Clojure was marketed as a configuration file format from the very start, without mentioning persistent immutable data structures, software transactional memory, and other scary words. Would it have more adoption now?

Re: Pkl, a Programming Language for Configuration

#339

Post by riffraff »

mardifoufs wrote: post #274
criddell wrote: post #193

Earlier quoted context omitted.

I think the answer to your question is yes: LSPs can’t do everything that a plugin can do. https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d...

That sounds like a limitation on Jetbrains part, no? Or is it due to LSPs themselves?

I suppose there are things which are just beyond the scope of LSP, like menus and other UI bits which are IDE specific, not to mention refactoring tools etc.
Post reply on HN