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

Cue – A language for defining, generating, and validating data

cuelang.org

Post reply on HN
Print view View original

101–110 of 167 posts

Re: Cue – A language for defining, generating, and validating data

#101

Post by ptest1 »

cwp wrote: post #78
bipolar_lisper wrote: post #29

A new configuration language. Yes. That's exactly what we need.

I realize this was meant to be sarcastic. However, I whole-heartedly and unironically agree. For writing small bits of configuration, just about any language will be fine. For large amounts of configuration, as is required for... oh, I dunno, let's say deploying software in the cloud, all the commonly used languages are a disaster. Data serialization languages (like JSON, INI, XML, etc) lack the power to describe lar…

I wholeheartedly and in ironically disagree!

We have all we need. If you want a full featured language, use that. Beyond that, we have JSON, YAML, INI and more. If you want something more complicated you can create your own DSL for your app.

If you want schemas and validation, use XML!

Re: Cue – A language for defining, generating, and validating data

#102

Post by ptest1 »

dbcurtis wrote: post #57
mikl wrote: post #47

Earlier quoted context omitted.

We do indeed. XML is awful, YAML is a clusterfuck, JSON is often insufficient, and so is INI. TOML looks promising, but might not make it out of its niche. If Cue is basically a better YAML with built-in schemas, that sounds pretty good.

I was hoping to like TOML, but my first experiments using a Python package for parsing it were disappointing. I found the syntax cranky, and the Python package I was using did a terrible job at providing diagnostics — very poor exception propagation. And that seemed to be the most mature TOML parser that I could find for Python, so I decided TOML isn’t likely in my future.

TOML is extremely verbose for lists. It’s ridiculous. Sure it had less features than YAML but it also looks considerably worse in all the common use cases. Looks like INI

Re: Cue – A language for defining, generating, and validating data

#103

Post by [deleted] »

justicezyx wrote: post #53
joatmon-snoo wrote: post #52

Earlier quoted context omitted.

We still haven't. :(

As I alluded in the other comment, there needs to be a better tool for BCL, not the language. GCL, used outside borg, is a much more pleasing experience, because there is a decent tool. And the team have done good job to innovate continuously.

[deleted]

Re: Cue – A language for defining, generating, and validating data

#104

Post by locusofself »

hestefisk wrote: post #85

If configuration starts becoming more complex than looking up key value pairs, why not just write it in the programming language you are using? More languages / serialisation just adds another layer of complexity. Config as code is actually really neat.

how does this apply to compiled languages though?

Re: Cue – A language for defining, generating, and validating data

#105

Post by uryga »

wlib wrote: post #86

I'm feeling both really pissed and validated right now. I thought this was going to just be a normal thoughtless config language that would only be successful as a Google project. Then I looked at the theoretical basis page. I have no formal proof about this, but I've been talking about this type of a type system with my parents and high school CS teacher for a while now! My idea sounds like this: a value is simply a…

> Of course, this leads to type -> type functions which describe dependent and refinement types naturally.

could you expand on this? i don't understand how you get this from grammars.

(on a side note, i think that dependent types usually mean you can write functions from values to types, not type -> type?)

Re: Cue – A language for defining, generating, and validating data

#106

Post by ptest1 »

fareesh wrote: post #60

I feel like that validation feature could theoretically save a lot of people that occasional 1 hour of their time that was wasted because of a typo in a config file leading to a cryptic error message.

This is literally a feature of XML everyone complained about when JSON was the hottest thing, though.

Re: Cue – A language for defining, generating, and validating data

#107

Post by smt88 »

lonelappde wrote: post #69
smt88 wrote: post #55

Earlier quoted context omitted.

> maintained by a properly staffed team This seems to describe very few Google products. Almost daily, I have the following thought: "Has anyone at Google actually even used this product?" (Most often with Assistant, but definitely with other products, too)

Just because you don't like doesn't mean it's not built and supported by a large team following some VP or PM vision. Boondoggles cost a lot of resources.

Perhaps I have a different definition of "maintained" than Google does. For me, it means that it's not just online, but also has bugs regularly fixed and features added.

Most Google services (off the top of my head: Voice, Talk, Reminders) seem to reach v1 and then stop dead in their tracks. They're online, but that's it. Thousands of people request fixes or features, and they go completely unheard.

Google employees on HN have confirmed this, saying that the company rewards new products that drive ads, but not the work involved in improving and maintaining existing products. That explains why Google's released the following products for messaging, and none has been amazing: Talk, Hangouts, Voice, Wave, Allo, Hangouts Chat, and Messages/RCS.

Most of these overlapped at some point, and if you've used any of them, you wouldn't describe them as "maintained". They're more like "abandoned without publicly announcing anything".

If there's a VP or PM vision anywhere at Google that lasts for more than a year, I'd love to know what it is. It seems like a company with a thousand committees and no real creative leadership.

Re: Cue – A language for defining, generating, and validating data

#108

Post by __david__ »

ptest1 wrote: post #95
mikl wrote: post #49

Earlier quoted context omitted.

Less footguns, built-in validation, strong types. Me gusta.

So..why not use XML?

So that humans eyes don't bleed when they try to read it.

One of the things they bring up in the docs is lessening boilerplate. And it's hard to get more boilerplatey than XML.

Re: Cue – A language for defining, generating, and validating data

#109

Post by dbcurtis »

ptest1 wrote: post #102
dbcurtis wrote: post #57

Earlier quoted context omitted.

I was hoping to like TOML, but my first experiments using a Python package for parsing it were disappointing. I found the syntax cranky, and the Python package I was using did a terrible job at providing diagnostics — very poor exception propagation. And that seemed to be the most mature TOML parser that I could find for Python, so I decided TOML isn’t likely in my future.

TOML is extremely verbose for lists. It’s ridiculous. Sure it had less features than YAML but it also looks considerably worse in all the common use cases. Looks like INI

Yeah, I was fighting the list problem. And not able to mix numeric and string data in a list just made the whole thing unwieldy and frustrated me.

I’ve used JSON for configs, which is not great, but at least readable. The biggest problem is lack of comments, but I added a quick hack to ignore any dictionary key starting with an octothorpe. Not ideal, but is actually handy because it makes it easy to comment out keys temporarily as well as add arbitrary commentary.

Also, the Python standard library JSON parser is very flexible and yields precise exceptions. I was able to turn those parsing exceptions into meaningful error messages with precise line and column numbers. Which came as a bit of a shock to some of my users, because a different tool written before my time but used by the same people had exactly one error message for mispelled YAML: segfault.

Re: Cue – A language for defining, generating, and validating data

#110

Post by hestefisk »

locusofself wrote: post #104
hestefisk wrote: post #85

If configuration starts becoming more complex than looking up key value pairs, why not just write it in the programming language you are using? More languages / serialisation just adds another layer of complexity. Config as code is actually really neat.

how does this apply to compiled languages though?

Recompile when config changes.
Post reply on HN