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

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 performance.

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

#6

Post by scrame » Sun, Aug 20, 2023, 5:43 AM UTC

CoastalCoder wrote: post #2

2019

does that invalidate the criticisms?

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

#7

Post by gary_0 » Sun, Aug 20, 2023, 5:50 AM UTC

scrame wrote: post #6

CoastalCoder wrote: post #2

2019

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.

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

#8

Post by eesmith » Sun, Aug 20, 2023, 5:53 AM UTC

signa11 wrote: post #3

CoastalCoder wrote: post #2

2019

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 there is no consistency about where people post a date, or if there is one at all.

I know that I sometimes skim the HN comments first rather than follow a page link because then I don't need to worry about cookie notices, requests to subscribe to a newsletter, etc. This essay does not have those, but enough do that it's a general nuisance.

2) Software changes over time. Cap'n Proto's Schema language may have changed since then - perhaps as a response to this essay - making this essay of historic interest only. While that is not likely the case, it is an example of how having the date may provide helpful information.

This is useful enough that it is accepted practice to add the date to older information. For example, the previous two HN submissions to this essay both include (2019) in the title. See https://news.ycombinator.com/from?site=zenhack.net

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

#9

Post by signa11 » Sun, Aug 20, 2023, 7:00 AM UTC

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…

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.

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

#10

Post by jiggawatts » Sun, Aug 20, 2023, 7:09 AM UTC

signa11 wrote: post #9

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…

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.