Overall, I love how this looks -- it's a nice evolution of protobufs.

I had a couple issues/questions while reading through the site, so I'll just throw them in here:

> struct Date {
> year @0 :Int16;
> month @1 :UInt8;
> day @2 :UInt8;
> }

That's a fairly awkward syntax, even more than .proto files. I notice your compiler is written in Haskell, so it should be pretty easy to define a human-friendly syntax and parse it with Attoparsec and friends. In particular, the use of colons and semicolons here seems unnecessary.

Are you set on that syntax, or would you accept patches to change it? I don't know how much breaking change you'd be willing to accept at this point.

> Fields (and enum values, and interface methods) must
> be numbered consecutively starting from zero in the
> order in which they were added.

I disagree with this decision. Being able to set tag numbers in arbitrary order makes reading the text format of a proto message (e.g. during debugging) much nicer, because fields can be grouped according to their purpose rather than whenever they happened to be added to a message.

Speaking of which, I don't see any specification for a text-based serialization format on this site. If I were you, I'd just steal Protobuf's because it's simple and easy to read/write.

> Unlike Protobufs, you cannot skip numbers when defining
> fields – but there was never any reason to do so anyway.

For me, the reason to skip field numbers is when some older version of the message defined some field, but new messages removed it and clients should not know about it. Typically, I indicate this by replacing the field definition with a comment to ensure the field number isn't accidentally re-used. This reduces the amount of legacy cruft in .proto files.

> GCC 4.7 Needed
>
> If you are using GCC, you MUST use at least version
> 4.7 as Cap’n Proto uses recently-implemented C++11
> features. If you are using some other compiler…
> good luck.

One of the best features of protobufs is that they are easily portable between many platforms and languages. If the C++ implementation requires advanced modern compiler features, that will severely reduce the number of developers who are able to use it. It would be better to write the reference implementation such that it's supported even by ancient compilers, so that users don't have to worry about upgrading lots of other packages just to try out CAPNP.

> For example, exceptions are thrown on assertion
> failures (indicating bugs in the code), network
> failures, and invalid input. Exceptions thrown by
> Cap’n Proto are never part of the interface and
> never need to be caught in correct usage.

I'm fine with making assertion failures throw exceptions that "never need to be caught", but network failures and invalid input are very much things that should be treated as common events.

Error reporting (via return values or out-parameters) will make the interface slightly less elegant. This is fine. The benefit of having proper error handling by far outweighs minor verbosity of error checking.

> Text: Like Data, but the content must be valid
> UTF-8, the last byte of the content must be zero,
> and no other byte of the content can be zero.

If there's a length prefix, why bother with a terminating NUL? D-Bus does the same thing, and it serves no reason except to add another possible error condition.

> So when Directory.open is called remotely, the
> content of a FileInfo (including values for name
> and size) is transmitted back, but for the file field,
> only the address of some remote File object is sent.

It's not obvious how such address-passing can be implemented, without falling into the black hole that is CORBA. I don't see anything on the encoding page about it, either. Is an address some sort of 64-bit cookie, a string, or something more complex? How does using addresses work when the server is written in a language that doesn't have the concept of addressable values?

> The Cap’n Proto RPC protocol is not yet defined.
> See the language spec’s section on interfaces for a
> hint of what it will do.

Roughly what is the timeline for defining the RPC protocol? I've been working on a Protobuf-based RPC protocol for a while (it'll replace my use of D-Bus for inter-machine and low-overhead inter-process communication), but it probably won't be in even a beta state for at least another two or three months. If you don't have any immediate plans, I'd love to merge my work into CAPNP.