3 ms·

After I dug more into Cue, it's actually super complicated and ugly. Jsonnet is definitely cleaner and easier to learn if TOML is too static for you. It's nice

After I dug more into Cue, it's actually super complicated and ugly. Jsonnet is definitely cleaner and easier to learn if TOML is too static for you. It's nice to have type safety, but the way it's implemented in Cue is unintuitive and too complex to be practical. The approach of JSON (borrowed from XML) to have a separate schema file is better and you can use to to just validate.

ithkuil 7y ago
It might be unintuitive (depending on youtlr background) but I wonder where do you see the complexity. It's actually one of the simplest approach to this problem space I've seen lately. I'm honestly curious about what are your concerns with it.
- nikolay 7y ago
  I am using Jsonnet daily. And I thought Jsonnet was weird - it took me a while to figure it our, and many of the developers on the team struggle with it. But most developers will have no clue with Cue - I guarantee you! It is not intuitive and a lot of things need to be memorized, looked up, etc. No wonder both Jsonnet and Cue arrive from Google!
  - ithkuil 7y ago
    It's indeed a hard problem in language design: the amount of investment people are willing to make depends on so many factors, like pre-existing adoption/popularity, and how often you need to use it to get some other work done. Contrast it with the programming language you use at your day job. Chances are that you invested many hours in order to learn it properly and probably you don't think you necessarily have exhausted things to learn about it. It also probably has many quirks and emerging complexity that wasn't obvious to the its designers or resulted from trade-offs. Yet we put up with all this because, well because we have no choice. When you need to get something done that needs writing some code, you need to enter the realm of programming languages and people build their careers around mastering them. The problem around configurations is often underrated. Solutions to the problem of not even wanting to learn a new thing ranges from "It's just configuration after all, why can't it be just some basic structures and if you need more you're clearly doing something wrong" to "well just stick your $favourite_language as a template engine and you can emit whatever you want". Jsonnet strikes a nice balance and I like it. It's easy to grasp for those who know some functional programming languages and being untyped you can gloss over a sizeable amount of learning curve. But those shortcuts don't come for free. I use jsonnet at dayjob and the general feeling is that things do get complex white quickly and it's hard to know where values come from. I always thought that with some effort we could add some nice tooling to help with all of that, but cue caught my eye and I'm willing to give it a shot.
    - nikolay 7y ago
      My issues with Jsonnet is: - weird std lib, which doesn't follow other popular std libs - for example, JavaScript; - the inability to have dynamic import paths - the author cites some security reasons, but I don't buy them; - no wildcard imports! - lazy evaluation is a paradigm many struggle with; - redundant 'local' keyword - Bash-like, should have used 'var' or 'let' instead; - slow! - `importstr` does not follow Linux conventions about trailing newline; - no type safety! - could borrow some operators from Cue! - no native support for YAML and TOML! And many more!
      - ithkuil 7y ago
        All valid points. Fwiw, in https://github.com/bitnami/kubecfg https://github.com/bitnami/kubecfg we have added a native functions for yaml.

ithkuil 7y ago

It might be unintuitive (depending on youtlr background) but I wonder where do you see the complexity. It's actually one of the simplest approach to this problem space I've seen lately. I'm honestly curious about what are your concerns with it.

nikolay 7y ago
I am using Jsonnet daily. And I thought Jsonnet was weird - it took me a while to figure it our, and many of the developers on the team struggle with it. But most developers will have no clue with Cue - I guarantee you! It is not intuitive and a lot of things need to be memorized, looked up, etc. No wonder both Jsonnet and Cue arrive from Google!
- ithkuil 7y ago
  It's indeed a hard problem in language design: the amount of investment people are willing to make depends on so many factors, like pre-existing adoption/popularity, and how often you need to use it to get some other work done. Contrast it with the programming language you use at your day job. Chances are that you invested many hours in order to learn it properly and probably you don't think you necessarily have exhausted things to learn about it. It also probably has many quirks and emerging complexity that wasn't obvious to the its designers or resulted from trade-offs. Yet we put up with all this because, well because we have no choice. When you need to get something done that needs writing some code, you need to enter the realm of programming languages and people build their careers around mastering them. The problem around configurations is often underrated. Solutions to the problem of not even wanting to learn a new thing ranges from "It's just configuration after all, why can't it be just some basic structures and if you need more you're clearly doing something wrong" to "well just stick your $favourite_language as a template engine and you can emit whatever you want". Jsonnet strikes a nice balance and I like it. It's easy to grasp for those who know some functional programming languages and being untyped you can gloss over a sizeable amount of learning curve. But those shortcuts don't come for free. I use jsonnet at dayjob and the general feeling is that things do get complex white quickly and it's hard to know where values come from. I always thought that with some effort we could add some nice tooling to help with all of that, but cue caught my eye and I'm willing to give it a shot.
  - nikolay 7y ago
    My issues with Jsonnet is: - weird std lib, which doesn't follow other popular std libs - for example, JavaScript; - the inability to have dynamic import paths - the author cites some security reasons, but I don't buy them; - no wildcard imports! - lazy evaluation is a paradigm many struggle with; - redundant 'local' keyword - Bash-like, should have used 'var' or 'let' instead; - slow! - `importstr` does not follow Linux conventions about trailing newline; - no type safety! - could borrow some operators from Cue! - no native support for YAML and TOML! And many more!
    - ithkuil 7y ago
      All valid points. Fwiw, in https://github.com/bitnami/kubecfg https://github.com/bitnami/kubecfg we have added a native functions for yaml.