▲ | i_s 3 days ago | |||||||
KSON looks interesting. Where I work we did a metadata type project in Pkl recently, which is somewhat similar. Unfortunately, developments on the tooling front for Pkl have taken an extremely very long time. Not sure the the tooling/LSPs are anywhere close to what the language offers yet. I like the language embedding feature in KSON - we would use that. Have you thought about having functions and variables? That is something you get in Pkl and Dhall which are useful. | ||||||||
▲ | dmarcotte 2 days ago | parent | next [-] | |||||||
Thanks, i_s. Daniel chiming in here... for functions and variables, we intentionally stay focused on JSON/YAML-equivalent data because the places where JSON or YAML are used as human-edited interfaces (because of their limitations rather than in spite of them) is the slice of the programming stack that KSON is particularly interested in. If the next Kubernetes/GitHub Actions/dbt/etc wants to reach for a language to be their interface, KSON is interested in providing everything YAML offers and more (AND less: less of the problems associated with YAML) We have a design for KSON constants that we're looking forward to sharing soon, but they will be constant and KSON will still be JSON/YAML-equivalent. For the places where someone wants more programming power in their config, I'm glad people like the folks behind Pkl and Dhall are serving that use case. | ||||||||
▲ | wofo 2 days ago | parent | prev | next [-] | |||||||
Thanks for the kind words :) This sounds like the kind of question for Daniel himself to chime in, since he has the best overview of the language's design and vision. He's not super active on HN, but I'll give him a heads up! Otherwise feel free to join our Zulip (https://kson-org.zulipchat.com) and we can chat over there. | ||||||||
▲ | islon 2 days ago | parent | prev [-] | |||||||
What kind of tooling are you missing in Pkl? | ||||||||
|