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

The Sandstorm Team Is Joining Cloudflare

sandstorm.io

Post reply on HN
Print view View original

101–108 of 108 posts

Re: The Sandstorm Team Is Joining Cloudflare

#101

Post by frik »

nostrademons wrote: post #99
praneshp wrote: post #94

Earlier quoted context omitted.

I started commuting on Caltrain (Mountain View SF) 3 months ago. For me it's quite easy to read a book on the onward trip and work on the return trip. The only time I'm annoyed is when I board in the morning, people never stand in a line (like BART). They just approach the coach from all directions and pile inside. But it's empty enough that I can wait till everybody gets in, and I will still get a free seat/comforta…

I did Santa Clara -> 22nd a couple years ago when I had a cofounder who lived in the city. I found I ended up writing a significant amount of code for that startup on the train. It actually worked out pretty well; I'd put the finishing touches on features on the way in, then discuss with my cofounder, figure out what we needed to do next, maybe talk to some potential users in the city, and write the code for new feat…

That's a very good point. Working from train often means spotty internet connection. So it's hard to instantly look up something in Google. A good offline documentation helps. For older languages and IDEs like C and C++ and Visual Studio 2005 like 10 years there were CHM help files for everything. Nowadays almost everything is available almost only as web help, if there is even an official full documentation at all. Also like 10 years ago, books came with an CHM file on CD/download. Nowadays books are already outdated when the get published, things like App and Web development is moving very fast. So starting a new project on train is not a good idea, fixing bugs from error/warning messages isn't a good idea, but doing some maintenance/refactoring work is well suited for boring train rides.

Re: The Sandstorm Team Is Joining Cloudflare

#102

Post by kentonv »

nurettin wrote: post #98
doh wrote: post #60

Earlier quoted context omitted.

1) Cap'n Proto doesn't encode/decode messages thus it's nuch cheaper for processing and memory management 2) protobuf in the proto3 design doesn't cary default values. So if you have a bool field and want to explicitly send false, well you have to change it to some other type or use the default values all the time 3) protobuf generates incredibly large serialization/deserialization support coce for each template. For…

I use protobuf-generated RTTI for the purpose of doing endpoint SQL storage of the messages. (tables, columns, foreign keys, insert/select statements are all auto-generated from the protobuf message) using C++. Does capnproto provide similar RTTI information to walk through properties or recurse into other messages?

Absolutely. I was the one who originally designed the Protobuf RTTI (aka "reflection") interface, after all... :)

It's actually considerably easier to implement for Cap'n Proto since the in-memory objects are actually backed by byte buffers containing the wire format. No need to compute offsets of class members (which technically violates the C++ standard though it works on all compilers).

Re: The Sandstorm Team Is Joining Cloudflare

#103

Post by kentonv »

frik wrote: post #101
nostrademons wrote: post #99

Earlier quoted context omitted.

I did Santa Clara -> 22nd a couple years ago when I had a cofounder who lived in the city. I found I ended up writing a significant amount of code for that startup on the train. It actually worked out pretty well; I'd put the finishing touches on features on the way in, then discuss with my cofounder, figure out what we needed to do next, maybe talk to some potential users in the city, and write the code for new feat…

That's a very good point. Working from train often means spotty internet connection. So it's hard to instantly look up something in Google. A good offline documentation helps. For older languages and IDEs like C and C++ and Visual Studio 2005 like 10 years there were CHM help files for everything. Nowadays almost everything is available almost only as web help, if there is even an official full documentation at all.…

Honestly it's absurd that the Caltrain doesn't have wifi yet. So many non-techy cities have it on their commuter rail lines...

Re: The Sandstorm Team Is Joining Cloudflare

#104

Post by kentonv »

sandGorgon wrote: post #100
kentonv wrote: post #9

Hi all, I'm not sure how responsive I'll be able to be on this thread since I'm in orientation today. :) But, here's the things I expect to be repeating a lot: - Sandstorm is still an independent company, under control of Jade and myself. - Sandstorm is "my baby" and I'm not going to stop working on it just because I have a day job. Yes, it will slow down a bit -- but on the bright side, we were previously spending t…

are you planning to have a pure-python implementation at some point ? I understand about the performance... but there are many usecases where a pure python implementation is far more practical.

I don't have specific plans regarding language support -- mostly that's been up to contributors so far, with me focusing on the C++ "reference" implementation. Hopefully, though, at CF we can find more resources. (The author of pycapnp, Jason Paryani, also joined CF with us, FWIW.)

Re: The Sandstorm Team Is Joining Cloudflare

#105

Post by doh »

euyyn wrote: post #92
doh wrote: post #60

Earlier quoted context omitted.

1) Cap'n Proto doesn't encode/decode messages thus it's nuch cheaper for processing and memory management 2) protobuf in the proto3 design doesn't cary default values. So if you have a bool field and want to explicitly send false, well you have to change it to some other type or use the default values all the time 3) protobuf generates incredibly large serialization/deserialization support coce for each template. For…

(2) is explicitly one of the reasons to use proto3 over proto2, though :) It's weird seeing it listed as a disadvantage instead of the other way around.

Depends on the use case. For instance if you're mapping the data to database, you can't send null variables. Or you store the defaults (waste of space) or you send it as another type.

In our case we've now over 1T of rows. Storing default variables would be incredibly inefficient and expensive.

Re: The Sandstorm Team Is Joining Cloudflare

#106

Post by kordless »

anonymousDan wrote: post #87
kordless wrote: post #81

Earlier quoted context omitted.

The investment market for infrastructure software is difficult now. Some might put it another way, but I think it's challenging given the way that current market model choice moves back and forth between a preference for private or public offerings. Consider the evolution steps from MSPs to SaaS. Of late, offerings that provide a hybrid approach to software seem to be emerging. Gravitational and Relicated are example…

When you say hybrid, do you mean hybrid for the same customer (i.e. parts or instances of the service running at the same time on-premise and in the cloud) or for different customers (i.e. a particular customer will either run on-premise or in the cloud, but not both)?

Both. I'm not a big fan of the term hybrid given the past use of it to describe cloud services. I think of it more like managed SaaS services, where a customer might buy software licensing by the month and run it just on-prem, on-prem and hosted, or just hosted. I can also see a third option where there's an MSP like entity running code on your hosted infrastructure, but licensing software both on-prem (running on your stuff) and then bits running in the cloud as a solution to burst-based problems. AI services will definitely manifest this way.

Re: The Sandstorm Team Is Joining Cloudflare

#107

Post by praneshp »

kentonv wrote: post #103
frik wrote: post #101

Earlier quoted context omitted.

That's a very good point. Working from train often means spotty internet connection. So it's hard to instantly look up something in Google. A good offline documentation helps. For older languages and IDEs like C and C++ and Visual Studio 2005 like 10 years there were CHM help files for everything. Nowadays almost everything is available almost only as web help, if there is even an official full documentation at all.…

Honestly it's absurd that the Caltrain doesn't have wifi yet. So many non-techy cities have it on their commuter rail lines...

It's not absurd to me anymore, I "get" how CA, and the bay area especially, operate now :) I've heard good things about Verizon, and I personally use a Project Fi phone as a hotspot. It's decent enough for hackernews/reddit/google/stackoverflow, except for the tunnels right outside the city.

Re: The Sandstorm Team Is Joining Cloudflare

#108

Post by euyyn »

doh wrote: post #105
euyyn wrote: post #92

Earlier quoted context omitted.

(2) is explicitly one of the reasons to use proto3 over proto2, though :) It's weird seeing it listed as a disadvantage instead of the other way around.

Depends on the use case. For instance if you're mapping the data to database, you can't send null variables. Or you store the defaults (waste of space) or you send it as another type. In our case we've now over 1T of rows. Storing default variables would be incredibly inefficient and expensive.

I'm not understanding your case much. Proto3 does not serialize zeros/false, precisely because it'd be a waste without a benefit. After deserialization, the value is as equal to zero as if the zero had been written on the wire or on disk. Why would you want to store that?

Is nullability of primitive types what you're missing? As in, having a boolean value that can be true, false, or null. If you need that, defining your field as google.protobuf.BoolValue instead of bool gives you that (same with the other primitive types: https://github.com/google/protobuf/blob/master/src/google/pr... ). But making primitive types never null aligns proto3 with most programming languages, making the generated code more idiomatic and performant.

Post reply on HN