The counter could be that we don't want anything from the big corp either.
But regardless, would you think anything new will become mainstream in this space? We already have json, yaml, perhaps a few more. It appears that the problem that the new ones solve start paying off when the software they configure go over some pretty high complexity threshold.
I mean there would be better reasons to not use Go or Kubernetes than just that they're Google tech. Both can add tremendous overheads to otherwise simple prototypes. Here, a Google aversion can be more pronounced because the thing is not obviously a bad choice.
With Cue, I personally think it is uglier than TOML and Dhall and only slightly less reader-ambiguous than YAML. But it’s like game theory: you have these strategies you add in the middle which come with half the costs and half the benefits and so they aren't strongly dominated by any of the other options and they get their fair share of the Nash equilibrium because they occupy that middle ground. So if one cannot say “this is clearly a wrong choice” one can nevertheless default to “this is a possible choice but I just have a lot of options and I can choose to be more arbitrary about what's important to me.
At one point in the early 00s I needed a shared hosting provider for a small site, and all of them looked unbelievably the same. I adopted the first narrowing criterion of “Reject any hosting provider which has a name of two words mashed together in PascalCase”, which IIRC cleared away well over half of the competition. There's nothing wrong with them, I just had a lot of options so I could afford to say “this looks so ugly and repetitive to me and I don't want to do it.”
That cleared away a lot but not enough to narrow it down to a few options, so I then arbitrarily limited it again, “no free hosting providers whose Contact Us links contain stock photography of a solitary white woman wearing a headset.” (Like she can be in a group, she can be a minority race, she can be holding a phone, she can be an actual employee of the given company, it could be somewhere else where it is not a link you click on, like a splash page—any of those is fine, just stop trying to suggest “we are trendy and support diversity but not so much diversity that you worry your precious white man head about being routed to a call center.”) That one was actually unreasonably effective and got it down another 80-90% or so to a manageable handful.
When you have a lot of middling options that cannot strictly be eliminated for technical merit the soft things are valuable for winnowing.
>With Cue, I personally think it is uglier than TOML and Dhall and only slightly less reader-ambiguous than YAML
I think you're missing the main point of these languages.
YAML, TOML, JSON are all basically the same thing modulo syntactic differences, which are largely a matter of taste.
Dhall, Cue, Jsonnet, BCL, etc. are in a different league - they allow you to express some computations with data in your config. It helps you to eliminate boilerplate and duplication in your config, avoid copy-paste mistakes, make configs more concise, express some complex abstractions specific to your domain. They're miniature programming languages for your configuration data.
If all you have is a few dozen key/value pairs to specify, it doesn't really matter which you choose, just a matter of taste. But as your config files suddenly span thousands LoC, duplicate same things over and over, need to configure dozens of different things (e.g. with jsonnet out of a single jsonnet source you can generate multiple configs for basically anything json/yaml/ini driven), get edited by multiple teams and you start looking for better ways to structure this mess, that's when these more advanced config languages come in to rescue your sanity.
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.
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!
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.
I do, but these are more complex things where they actually add some type of value (even if it's "this is safe to use because it will be around forever since this big company has vested a lot into it"). But cue is a config language which in itself is a niche area. Also, it is much simpler to rewrite configs from one language to the other, so it's safer to choose the "weird" one.
But regardless, would you think anything new will become mainstream in this space? We already have json, yaml, perhaps a few more. It appears that the problem that the new ones solve start paying off when the software they configure go over some pretty high complexity threshold.