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

Buf raises $93M to deprecate REST/JSON

buf.build

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Buf raises $93M to deprecate REST/JSON

#71

Post by digitailor »

catsarebetter wrote: post #59
kentonv wrote: post #47

Earlier quoted context omitted.

TBH not really. I've talked to the founder a few times. He doesn't want to put his name on things, as he's kind of a private person and really wants to direct the spotlight at his employees. But he's just an engineer who has spent a lot of time working with Protobufs, not a sales person at all. (Disclosure: I was the maintainer of Protobuf who put together the first open source release at Google, and I made a small i…

Ok now I'm pretty interested in this company: 1. Very technical founder at the bleeding edge of the field. 2. Many people against this idea Usually a sign there's something really good here... or at least something that is super non-obvious to most people. I'm curious to learn what I'm missing... mind if I reach out?

The exuberant behavior of the VCs is really what's being noted. The core business could very well be sound. One just has to hope the very technical founder is being well advised.

This is a press release after all

Re: Buf raises $93M to deprecate REST/JSON

#72

Post by sergueif »

kentonv wrote: post #58
ChuckMcM wrote: post #52

Wow, “Oh look, we’re going to re-invent the wheel for what is at least the third time.” When I worked at Google I sat down one day across from one of the gRPC engineering leads who was talking about the things they were doing for the then current generation of gRPC. I asked if I could ask some questions about it and they agreed and then dissected their design in half a dozen ways that would fail in both non-important…

Note that Buf is building tooling around Protobuf/gRPC, not replacing them. Maybe I'm just another clueless millennial developer who doesn't understand the history of the 80's or whatever, but I've never been able to understand this claim that RPC is broken. There's a lot of assertions that everyone knows RPC was broken because smart people in the 80's said so but... no one has ever been able to give me a concrete re…

the term "RPC" can be unpacked with a lot of bad baggage. "remote" can imply unnecessary coupling of knowing the exact receiver. "procedure" can imply a hard guarantee that some side effect took place by the time you get a response.

"non-RPC", as best I can interpret it, means "broadcasting" useful messages / FYIs without much out-of-band coupling and listening for interesting messages. You don't know who's gonna receive the message, what they'll do with it, "when" they'll act on it.

RPC is inspired by "procedure call" on a single CPU, which is the complete opposite. in a "procedure call" you know exactly the implementation you're gonna get, when it will be executed, etc.

You can find glimpses of this in lots of companies, when there's heavy use of a message bus like Kafka. Protobufs as "messages" instead of mere procedure "call" arguments.

What do you think?

Re: Buf raises $93M to deprecate REST/JSON

#73

Post by xyzzy_plugh »

ChuckMcM wrote: post #65
kentonv wrote: post #58

Earlier quoted context omitted.

Note that Buf is building tooling around Protobuf/gRPC, not replacing them. Maybe I'm just another clueless millennial developer who doesn't understand the history of the 80's or whatever, but I've never been able to understand this claim that RPC is broken. There's a lot of assertions that everyone knows RPC was broken because smart people in the 80's said so but... no one has ever been able to give me a concrete re…

The “promise” of RPC has been that you’re calling a procedure from your code that happens to be on a different piece of equipment. It may be in a completely different memory space and on completely different hardware. So “seamless distributed computing.” The basic premise being that you specify the interface and you can use tooling to build some skeleton code that makes the code the user writes look like any other co…

I don't disagree with anything you're saying but I believe you're missing the forest for the trees. The problem I see Buf and other companies trying to solve isn't RPC so much as IDL. Defining and managing schemas is incredibly painful. It doesn't matter if it's a remote network call, HTTP, binary blob over a socket, files on disk or a call to a local function. Defining, sharing and consuming the boundaries -- the interfaces -- rigorously is the painful part.

You're too caught up on the implementation details. If you solve the IDL problems, then you can simply change the implementation and no one is the wiser. grpc-gateway is maybe a good example?

> exactly what ASN.1 does

Okay I actually do disagree with this. ASN.1 is a whole different ballgame. What doesn't it do, besides the obvious complications leading to buggy and insecure implementations every other day?

Please don't use ASN.1

Re: Buf raises $93M to deprecate REST/JSON

#74

Post by xyzzy_plugh »

hn_throwaway_99 wrote: post #46

When shit like this happens, I just always think "I don't understand finance at all and never will." I read the company's primary blog blog post, https://buf.build/blog/api-design-is-stuck-in-the-past , about "schema driven development" and agree with a lot of it. Which is why I'm a huge fan of GraphQL and related completely free open source libraries, where I define my API endpoints with a strongly typed yet easily…

> Which is why I'm a huge fan of GraphQL and related completely free open source libraries

I don't understand this comparison. Apollo raised $130M this past summer -- doesn't seem that different to TFA. Is that also nuts to you?

The Protocol Buffers and gRPC ecosystem are also completely free open source libraries. Replace GraphQL with Protobuf and your post is still correct.

Re: Buf raises $93M to deprecate REST/JSON

#75

Post by kentonv »

ChuckMcM wrote: post #65
kentonv wrote: post #58

Earlier quoted context omitted.

Note that Buf is building tooling around Protobuf/gRPC, not replacing them. Maybe I'm just another clueless millennial developer who doesn't understand the history of the 80's or whatever, but I've never been able to understand this claim that RPC is broken. There's a lot of assertions that everyone knows RPC was broken because smart people in the 80's said so but... no one has ever been able to give me a concrete re…

The “promise” of RPC has been that you’re calling a procedure from your code that happens to be on a different piece of equipment. It may be in a completely different memory space and on completely different hardware. So “seamless distributed computing.” The basic premise being that you specify the interface and you can use tooling to build some skeleton code that makes the code the user writes look like any other co…

No modern RPC system attempts to transparently emulate a local procedure call. Everyone who is seriously using these systems understands that an RPC is not equivalent to a local call. Everyone understands that the network introduces a host of new failure modes that must be considered, as well as latency and concurrency. RPC systems are used to simplify protocol development but it is understood that these are still protocols and they don't magically solve everything.

> that is exactly what ONC RPC does, and that is exactly what ASN.1 does, and that is exactly what DCS does.

Simply put, Protobuf and gRPC do it better. The developer experience is much better. The tooling is much better. The implementation is better-optimized. It's not a new concept, it's just a better implementation. That's all there is to it.

But anyway, Buf is not re-inventing this wheel, it's just building on Protobuf and gRPC. It seems like your beef is with Protobuf and gRPC, not Buf.

Re: Buf raises $93M to deprecate REST/JSON

#76

Post by kentonv »

ghostwriter wrote: post #66
kentonv wrote: post #61

Earlier quoted context omitted.

Sorry, I'm the author of Cap'n Proto and I think that article is full of shit. My previous commentary: https://news.ycombinator.com/item?id=18190005

Thanks for Cap'n Proto. It's better than ProtoBuf, but I prefer FlatBuffers even more. I think the article is clearly indicating the issues that a wider community of conventional type systems in their mainstream languages is not fully aware of. And I disagree with your comments. Firstly, I don't like that you are labelling the author of the article as a "PL design theorist who doesn't have a clue" (my interpretation…

> I see that you don't fully understand the problems of composability, compatibility, and versioning and are too eager to dismiss them based on your prior experience with inferior type systems.

> You are conflating your experience with particular conventional tooling with a general availability of superior type systems and toolings out there.

You literally quoted my project as one of your two examples of superior systems and now you're telling me I don't understand how superior systems work because I have no experience with them?

Re: Buf raises $93M to deprecate REST/JSON

#77

Post by ghostwriter »

kentonv wrote: post #76
ghostwriter wrote: post #66

Earlier quoted context omitted.

Thanks for Cap'n Proto. It's better than ProtoBuf, but I prefer FlatBuffers even more. I think the article is clearly indicating the issues that a wider community of conventional type systems in their mainstream languages is not fully aware of. And I disagree with your comments. Firstly, I don't like that you are labelling the author of the article as a "PL design theorist who doesn't have a clue" (my interpretation…

> I see that you don't fully understand the problems of composability, compatibility, and versioning and are too eager to dismiss them based on your prior experience with inferior type systems. > You are conflating your experience with particular conventional tooling with a general availability of superior type systems and toolings out there. You literally quoted my project as one of your two examples of superior sys…

These are not mutually exclusive things, as superiority of the systems is a multi-dimensional metric. I quoted cap'n proto as an alternative to protobuf that I would definitely choose over any protobuf, because in my book it does at least a few things better. Namely, the bits related to immutability & zero-copying, and random access. But at the same time I do not like and do not agree with your field optionality stance, as I think it is based on a false premise that a universal optionality is the only viable path towards compatibility. I will cite the original article regarding the matter to clarify this point:

> protobuffers achieve their promised time-traveling compatibility guarantees by silently doing the wrong thing by default. Of course, the cautious programmer can (and should) write code that performs sanity checks on received protobuffers. But if at every use-site you need to write defensive checks ensuring your data is sane, maybe that just means your deserialization step was too permissive. All you’ve managed to do is decentralize sanity-checking logic from a well-defined boundary and push the responsibility of doing it throughout your entire codebase.

This approach doesn't free you as a developer from having to maintain multiple code-paths as you claim to be able to avoid in your older comments ("you end up needing to maintain parallel code paths, leading to ugly and hard-to-test code").

Code paths are still there, they are now intertwined with your business logic as conditional checks on a field presence. At every calling site that utilises the schema.

That's one of the reasons why I prefer flatbuffers over cap'n proto when I have a choice, and it is the reason why I think that you are not fully aware of the issues that stem from the choices of protobuf and that are clearly manifested in ecosystems that model network communications via advanced type systems.

In fact, this comment from your linked thread suggests a similar idea - advanced type systems can provide a strict schema negotiation in semi-automated way, at a fraction of the effort required to maintain schemas with all-optional fields - https://news.ycombinator.com/item?id=18201601

Re: Buf raises $93M to deprecate REST/JSON

#78

Post by xtiansimon »

ChuckMcM wrote: post #65
kentonv wrote: post #58

Earlier quoted context omitted.

Note that Buf is building tooling around Protobuf/gRPC, not replacing them. Maybe I'm just another clueless millennial developer who doesn't understand the history of the 80's or whatever, but I've never been able to understand this claim that RPC is broken. There's a lot of assertions that everyone knows RPC was broken because smart people in the 80's said so but... no one has ever been able to give me a concrete re…

The “promise” of RPC has been that you’re calling a procedure from your code that happens to be on a different piece of equipment. It may be in a completely different memory space and on completely different hardware. So “seamless distributed computing.” The basic premise being that you specify the interface and you can use tooling to build some skeleton code that makes the code the user writes look like any other co…

> “So what I was suggesting originally is that Buf should try to explain what they are doing that these other systems failed to do…”

I was having a discussion online yesterday about writing research papers, and this exact line of argumentation was noted.

As I recall, the marketing version is called a ‘white paper’.

Re: Buf raises $93M to deprecate REST/JSON

#79

Post by tlackemann »

kentonv wrote: post #56
mbrodersen wrote: post #25

Yet another non-business grabbing $ from clueless investors. Surely there must be a word for the “we are grabbing $ from clueless investors” business model? WeWork is the poster child for that one.

I mean... I'm one of the investors... I'm also the former maintainer of Protobuf and former startup founder myself... but I could be clueless, yeah.

With all respect, I hope you don't have a lot of capital locked in this. Who is this company targeting? Google?

My company uses gRPC and it's an absolute nightmare but not so much to the point where we'd use a company like this to add on MORE costs to our infrastructure.

It baffles me people choose buzzword technology because "ex-googler" or whatever when 99% of companies that choose it will NEVER hit the scale it was meant for. Best of luck to the sales team. They'll be the driving force I'm sure.

REST is fine for 99% of companies. Long live REST.

Post reply on HN