I was interested to hear the argument up until "Ruby on Rails" showed up. If "Ruby on Rails" does what you need, that's great, but then I'd say you're barely programming anymore, just like writing HTML/CSS barely is programming.
If we just go down another level (where you would implement something like Ruby on Rails), the same question appears. Do we favor explicit logic over implicit relations? At that level, I'd say the rule of thumb that "explicit is better than implicit" pays off, because it's often not that much more code, and a lot of code builds on top.
If you read the article, you'll see that what Corral is right now (i.e. the supposed "next generation") is in fact being abandoned. It's a dead-end, at the very least.
Many languages in use today don't even have a (first class) concept of unions or structures, at least not in the sense that you are talking about. If you're talking about about "bloat" those contexts, you might want to start somewhere else...
>> The downside is then if you just get a message without knowing what it is about it's difficult to figure out.
You're saying that as if there was a clerk reading the message at the other end. If a computer program gets a message it doesn't "understand", it's not going to "figure it out" either way.
Worse, if you're a programmer that doesn't know the actual schema and you're trying to figure out what the schema might be just by looking at the data, you'll probably run into trouble.
I was talking purely about humans finding messages they don't have the schema for during the course of debugging. Computers do equally badly with JSON data and Cap'n Proto data they don't have the schema for.
A fake example scenario of what I'm talking about: Someone notices a server is producing way too many errors, they check the logs and see a bunch of "invalid request: ...." messages. The messages are JSON like {"api_version":2,"cpu_usage":0.57}. They figure out that the server monitoring system is forwarding stats to the wrong IP address. Even though they don't know the full schema of the messages, they get the gist and it helped debug. With Cap'n Proto that would have been a few nonsensical bytes.
I don't think this is a very big downside, so in general I like protocols like Cap'n Proto.
Perhaps a much bigger downside is that in most languages integrating code generation into the build pipeline is a pain in the ass, so it is way easier to use dynamic serialization protocols that don't require compiling a schema.
> You're saying that as if there was a clerk reading the message at the other end. If a computer program gets a message it doesn't "understand", it's not going to "figure it out" either way.
Self-describing formats do make backwards compatibility a bit easier. With Cap'n Proto, adding a new field in the middle will break consumers.
Nothing is competing with HTML on being what HTML is. Nothing is even close.
All text encodings in common use build on top of ANSI. The de-facto standard (now) is UTF-8 and there's no reason to change that.
IP really does move all the data around the entire internet (that's kind of in the name right there!).
Yes, there are variations, extensions and incompatibilities, but these things are not being re-invented all the time, exactly because these things are ubiquitous standards.
The manpower behind Linux is superior. Not sure if it's the "vast majority", but for many business cases following the GPL(v2) rules simply is not a problem.
Both the PS4 and the Nintendo Switch run on FreeBSD, by the way.
>Both the PS4 and the Nintendo Switch run on FreeBSD, by the way.
Not exactly from what I've read, the PS4 runs 'Orbis OS' which is based upon FreeBSD 9, meanwhile the Nintendo Switch is using the network stack from FreeBSD, but also stuff from Android and the custom OS they wrote for 3DS.
If we just go down another level (where you would implement something like Ruby on Rails), the same question appears. Do we favor explicit logic over implicit relations? At that level, I'd say the rule of thumb that "explicit is better than implicit" pays off, because it's often not that much more code, and a lot of code builds on top.