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

A Critique of the Cap'n Proto Schema Language (2019)

zenhack.net

Post reply on HN
Print view View original

11–20 of 73 posts

Re: A Critique of the Cap'n Proto Schema Language (2019)

#11

Post by klabb3 »

Great post, digestible without experience in capn proto specifics.

I really like that they talk in terms of “features carrying their own weight” and survey real world code to see what cases features solve for, and how (surprisingly little) certain features are actually used.

A side effect of dropping features when designing for code generation (in this case) is that it makes things more concise for everyone else as well, including the users.

There are generally no easy answers, but as a principle I think the burden of proof for new features should be high. “Oh it’s nice” is not enough, unless it’s trivial syntactic sugar. It should really be at least a strong need and ideally multiple needs per feature, so to say.

Re: A Critique of the Cap'n Proto Schema Language (2019)

#13

Post by gjvc »

eesmith wrote: post #8
signa11 wrote: post #3

Earlier quoted context omitted.

yes ?

Knowing that it's from a few years ago gives helpful information to the potential reader. 1) Someone may have read the essay before, remembered the point, but forgotten the exact title. It has, after all, been posted on HN twice before. Simply reading the comment that it's from 4 years ago may be enough to confirm that it's the same article, as it did with me. While the essay has the date right at the top, in general…

Knowing that it's from a few years ago gives helpful information to the potential reader.

because it's so difficult to find the date of publication before people waste their precious time goofing off from their overpaid jobs.

Re: A Critique of the Cap'n Proto Schema Language (2019)

#14

Post by woodruffw »

ardel95 wrote: post #5

I think one of the most desirable and under-appreciated goals of schema languages and serialization formats is safety. These tools are typically used in places that deal with untrusted inputs, and features and design choices can go a long way in either exposing or shielding developers from potential safety bugs. My read of Cap’n’Proto didn’t make it sound that safety was the highest priority. At least not above perfo…

I agree entirely, and this is one of my single greatest frustrations with the majority of the current popular IDLs/schema languages.

ASN.1 is hilariously bad in a lot of ways, but one thing it gets absolutely right is strong typing and being able to express constraints (ranges, values dependent on other values). That combined with a canonicalized encoding form (DER) goes a long way in making various error states unrepresentable.

Re: A Critique of the Cap'n Proto Schema Language (2019)

#15

Post by signa11 »

jiggawatts wrote: post #10
signa11 wrote: post #9

Earlier quoted context omitted.

hmm, i don’t understand how schema-languages can do anything about that though. afterall, you just serialize/de-serialize based on provided inputs, GIGO if you will. safety w.r.t bad/malicious inputs should be a ‘higher level’ concern afaik.

Safety means: garbage in, error out.

right, and it should not be left to the serialization layer for that.

Re: A Critique of the Cap'n Proto Schema Language (2019)

#16

Post by nullc »

ardel95 wrote: post #5

I think one of the most desirable and under-appreciated goals of schema languages and serialization formats is safety. These tools are typically used in places that deal with untrusted inputs, and features and design choices can go a long way in either exposing or shielding developers from potential safety bugs. My read of Cap’n’Proto didn’t make it sound that safety was the highest priority. At least not above perfo…

> and serialization formats is safety. These tools are typically used in places that deal with untrusted inputs, and features and design choices can go a long way in either exposing or shielding developers from potential safety bugs

My potentially incorrect understanding is that Cap'n Proto's zero copy nature means the serialization format IS the in-memory representation, which means that if you build a Cap'n Proto object on top of non-zeroed memory you can leak data in the padding when transmitting. [Presumably not an issue if the packed encoding is used rather than the zero-copy one]

Re: A Critique of the Cap'n Proto Schema Language (2019)

#18

Post by afiori »

signa11 wrote: post #15
jiggawatts wrote: post #10

Earlier quoted context omitted.

Safety means: garbage in, error out.

right, and it should not be left to the serialization layer for that.

it depends on what type of safety.

The schema language might for example allow you to specify that an input string/blob should be smaller than 10MB and refuse to deserialize it if it is longer, same for array/list/vector length.

Re: A Critique of the Cap'n Proto Schema Language (2019)

#19

Post by orhmeh09 »

eesmith wrote: post #8
signa11 wrote: post #3

Earlier quoted context omitted.

yes ?

Knowing that it's from a few years ago gives helpful information to the potential reader. 1) Someone may have read the essay before, remembered the point, but forgotten the exact title. It has, after all, been posted on HN twice before. Simply reading the comment that it's from 4 years ago may be enough to confirm that it's the same article, as it did with me. While the essay has the date right at the top, in general…

The submission guidelines contain no such allowance. They specify a very limited set of cases where the title of a submission can be modified from the web page title.

Re: A Critique of the Cap'n Proto Schema Language (2019)

#20

Post by orhmeh09 »

gary_0 wrote: post #7
scrame wrote: post #6

Earlier quoted context omitted.

does that invalidate the criticisms?

It's common on HN to note the date for reposts. The mods will usually add the year to the title if it's not included. So that's probably all that CoastalCoder was signaling.

Users are not advised to do this themselves. The submission guidelines contain no such allowance. They specify a very limited set of cases where the title of a submission can be modified from the web page title.
Post reply on HN