rules_jsonnet VS hof

I can definitely sympathize here - in every context, just straight JSON/YAML configuration seems never expressive enough, but the tooling created in response always seems to come with sharp edges.

Here are some of the things I appreciate about Jsonnet:

- It evals to JSON, so even though the semantics of the language are confusing, it is reasonably easy to eval and iterate on some Jsonnet until it emits what one is expecting - and after that, it's easy to create some validation tests so that regressions don't occur.

- It takes advantage of the fact that JSON is a lowest-common-denominator for many data serialization formats. YAML is technically a superset of JSON, so valid JSON is also valid YAML. Proto3 messages have a canonical JSON representation, so JSON can also adhere to protobuf schemas. This covers most "serialized data structure" use-cases I typically encounter (TOML and HCL are outliers, but many tools that accept those also accept equivalent JSON). This means that with a little bit of build-tool duct-taping, Jsonnet can be used to generate configurations for a wide variety of tooling.

- Jsonnet is itself a superset of JSON - so those more willing to write verbose JSON than learn Jsonnet can still write JSON that someone else can import/use elsewhere. Using Jsonnet does not preclude falling back to JSON.

- The tooling works well - installing the Jsonnet VSCode plugin brings in a code formatter that does an excellent job, and rules_jsonnet[0] provides good bazel integration, if that's your thing.

I'm excited about Jsonnet because now as long as other tool authors decide to consume JSON, I can more easily abstract away their verbosity without writing a purpose-built tool (looking at you, Kubernetes) without resorting to text templating (ahem Helm). Jsonnet might just be my "one JSON-generation language to rule them all"!

---

Though if Starlark is your thing, do checkout out skycfg[1]

[0] - https://github.com/bazelbuild/rules_jsonnet

[1] - https://github.com/stripe/skycfg

For a auth product, you probably should go with traditional code generation, not LLMs (re: all the unsolvable problems they have (hallucinations, incomplete code answers). For an auth product, you want something definite and reproducible, or you are asking for trouble.

If you are interested in a flexible code gen framework, I built one that had this very use case in mind. (https://github.com/hofstadter-io/hof)

I'd be happy to think / talk this through with you

I recently built a TUI for exploring and developing CUE, JSON, Yaml.

Large inspiration for the overall UX comes from the Bloomberg terminal, where every function is reachable with four letter shortcut from the command box. It was really the command box that I liked. I've also built a sort of "flex" panel component for the layout so you can create as many panels as you like.

https://docs.hofstadter.io/getting-started/hof-tui/

https://github.com/hofstadter-io/hof/tree/_dev/lib/tui

Many business analysts use SQL, have for a long time. They are probably not your target audience. With the problem being JAVA specific, you'd likely want to start there

This sounds similar to the goals of my hof tool (https://github.com/hofstadter-io/hof), lift type definitions out of code so they can be defined in one place, then generate the code for all the places. Is that sounding like what you are after?

Having built something similar, the biggest challenge for users is that they have to use a bespoke language, like WASP here. I suspect that it is also your biggest challenge as well.

Mine is built on CUE, which at least has the potential to become a more widely used language. CUE hasn't reached sufficient maturity for broader adoption yet, so I continue to face this same problem.

https://github.com/hofstadter-io/hof

Here's a big one I needed to get ChatGPT to do something more sophisticated with a JSON object response (predates functions and all that)

https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/pro...

It no longer worked after a model update some time ago, haven't tried recently.

I found codellama to be much better for this and require fewer instructions, an anecdotal validation for smaller, focussed models

I was surprised out how you can define arbitrary grammars using arbitrary formulation and it would follow it. Of course you have to redo the prompt every time there is an update... such a pain

https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/pro...

CUE is indeed a beautiful language, will get those mind juices flowing for sure!

There is more work to be done on the codec implementation, but if you just want to split yaml/json across files, CUE is a great option

You might also like my project, built on CUE: https://github.com/hofstadter-io/hof We have a TUI where you can explore and work with CUE, JSON, Yaml

You can pretty much make up any pseudo grammar like this one, which is a reduced JSON object that is close to CUE: https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/pro...

No need to be formal or use a standard format

Yea, in particular for this project, they have created a bespoke templating system.

You can get the same thing with Go text/templates by adding chat function(s) as custom a helper: https://github.com/hofstadter-io/hof/blob/_dev/lib/templates...

100% one of the best things about building a TUI is not having the pain of modern web development. I do think there is a way to have a CLI & TUI come from the same code, so you can get the best of both, or pick the best for the task at hand.

experiments in progress here: https://github.com/hofstadter-io/hof/tree/_dev/lib/tui