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

Cap’n Proto

capnproto.org

Post reply on HN
Print view View original

161–170 of 194 posts

Re: Cap’n Proto

#161

Post by anongoogler2 »

kentonv wrote: post #159
anongoogler2 wrote: post #151

Earlier quoted context omitted.

I could imagine implementing something like this as an alternate wire format and client library for protocol buffers. Can you outline the main reason you chose not to go this route? In particular, what aspects of the proto descriptor language don't fit Cap'n Proto? Or what aspects did you feel needed to be changed for some other reason?

To be clear, by "alternate wire format and client library for protobuf" you mean "reuse the protobuf IDL but change everything else", right? There are a few major reasons I didn't go that route: * The .proto language has a lot of weird quirks that I don't like. Some of the quirks are specific to the protobuf encoding (e.g. int32 vs. sint32 vs. fixed32 being different types), while other quirks have no particular rati…

Yeah that's what I meant. To me re-using the IDL would be a big plus because then all data can always be converted from one format to the other.

The reasons you gave make sense, although I'm not super familiar with the RPC aspect of protocol buffers so that's new to me.

Re: Cap’n Proto

#162

Post by kentonv »

anongoogler2 wrote: post #161
kentonv wrote: post #159

Earlier quoted context omitted.

To be clear, by "alternate wire format and client library for protobuf" you mean "reuse the protobuf IDL but change everything else", right? There are a few major reasons I didn't go that route: * The .proto language has a lot of weird quirks that I don't like. Some of the quirks are specific to the protobuf encoding (e.g. int32 vs. sint32 vs. fixed32 being different types), while other quirks have no particular rati…

Yeah that's what I meant. To me re-using the IDL would be a big plus because then all data can always be converted from one format to the other. The reasons you gave make sense, although I'm not super familiar with the RPC aspect of protocol buffers so that's new to me.

For cases that don't use features specific to one format or the other, it should be easy to write a tool that automatically converts between schema formats, FWIW.

Re: Cap’n Proto

#163

Post by [deleted] »

gpderetta wrote: post #114
cyphar wrote: post #99

Earlier quoted context omitted.

> > Integers use little-endian byte order because most CPUs are little-endian, and even big-endian CPUs usually have instructions for reading little-endian data. > sob There are a lot of things Intel has to account for, and frankly little-endian byte order isn't the worst of them, but it's pretty rotten. Writing 'EFCDAB8967452301' for 0x0123456789ABCDEF is perverse in the extreme. Why? Why? Little endian means that a…

AFAIK, POWER has supported LE for a while and at least linux on Power has moved to LE by default.

[deleted]

Re: Cap’n Proto

#164

Post by aidenn0 »

socmag wrote: post #160
socmag wrote: post #158

Earlier quoted context omitted.

I think there is a lot in common between Common Lisp, Python and JavaScript in general. For many years I was in the schemaless camp before JS came along. Then for a number of years I was in the self-describing camp because I was thinking that if we don't accept JavaScript and JSON are pretty fundamental on the web we're fools and everyone seemed to be passing around JSON. So in that period was thinking that MsgPack w…

Also I might add that I very quickly became quite disenchanted with the lack of types in JSON; and I'm sure many of us have come to that same conclusion. Really hope that it can be fixed at some point, but not holding my breath on that one. I think it will take a major effort to reform that format although I am hopeful now that we at least have UInt8Array and friends that are starting to expose a broader set of machi…

I've actually seen people use types with JSON. JSON objects are clearly more than sufficient to represent the data you need, and you can enforce the schema in a library. It's just a much less efficient form of something like protobufs.

Re: Cap’n Proto

#165

Post by jcoffland »

kentonv wrote: post #141
jcoffland wrote: post #79

Earlier quoted context omitted.

Recently I've started compiling more of my code for Windows using Mingw (or clang). Performance is very good and you can build in Linux for Windows inside a Docker container. You can even build Windows installers using NSIS. I've also tried to do this for OSX but with less success.

Cap'n Proto supports MinGW as a target platform. (It has also supported Cygwin since very early on.) However, Cap'n Proto is a library, so it needs to support whatever compiler the users of that library are using, and for the vast majority of Windows developers that's MSVC.

Right, but you should be able to compile a library with either MinGW or clang from Linux that your users can use with MSVC.

Re: Cap’n Proto

#166

Post by kentonv »

jcoffland wrote: post #165
kentonv wrote: post #141

Earlier quoted context omitted.

Cap'n Proto supports MinGW as a target platform. (It has also supported Cygwin since very early on.) However, Cap'n Proto is a library, so it needs to support whatever compiler the users of that library are using, and for the vast majority of Windows developers that's MSVC.

Right, but you should be able to compile a library with either MinGW or clang from Linux that your users can use with MSVC.

Not if it uses C++. MinGW uses the G++ ABI which is totally incompatible with the MSVC ABI.

(Also, a lot of the issues we face affect headers, which need to be compiled into the client projects.)

Re: Cap’n Proto

#170

Post by DonHopkins »

DonHopkins wrote: post #84
kentonv wrote: post #51

Earlier quoted context omitted.

Well, I could write a lot about this, but... In general, because I felt there was too much resistance to me pursuing ideas that I wanted to pursue. Google has become increasingly top-down, whereas it was fairly bottom-up when I started in 2005. That's not necessarily a bad thing, but I felt that I personally would be happier running a startup where I could call the shots. FWIW, if you just want to write code, be comf…

> and you don't care if you're implementing someone else's ideas and working for an advertising company FTFY

I'd be fascinated if someone who downvoted this would also be brave enough to explain why they're in denial that google is an advertising company.

It may not be that your ideas are crazy and bad, but rather that your sane good ideas simply aren't appropriate in the context of advertising.

Enough with the Stockholm syndrome. There are pleanty of perfectly great ideas that Google would never pay their employees to work on, however explicable or inexplicable the reason might be.

>A blow for mobile advertising: The next version of Safari will let users block ads on iPhones and iPads [1] : [...] An Apple realist might argue that its great rival Google makes more than 90 percent of its revenue from online advertising — a growing share of that on mobile, and a large share of that on iPhone. Indeed, Google alone makes about half of all global mobile advertising revenue. So anything that cuts back on mobile advertising revenue is primarily hurting its rival. (Google has been less friendly to adblockers than its “open” positioning would suggest.)

[1] http://www.niemanlab.org/2015/06/a-blow-for-mobile-advertisi...

Post reply on HN