Lol. Imagine trying to capture a market that is already mostly happy with what it's got, and for free.
And to then provide roi on 93m
Buf raises $93M to deprecate REST/JSON
11–20 of 91 posts
Re: Buf raises $93M to deprecate REST/JSON
#12Re: Buf raises $93M to deprecate REST/JSON
#13Lol. Imagine trying to capture a market that is already mostly happy with what it's got, and for free.
Re: Buf raises $93M to deprecate REST/JSON
#14If someone wants to use json.com to create a company to promote json - DM me.
Re: Buf raises $93M to deprecate REST/JSON
#15A binary format may save some bandwidth and be slightly harder to reverse engineer - at the cost of being easily introspectable out of the box during development.
I don't think there is enough value to sell something.
I hope it gains traction and cargo cuting companies with bored engineers start using them, so hopefully the next company I work with won't have some terribly complicated and unusable graphql but just protobufs.
Re: Buf raises $93M to deprecate REST/JSON
#16Hmm why do they need to raise so much cash every 9 months? Also does anyone here use them and have any thoughts about their product?
Re: Buf raises $93M to deprecate REST/JSON
#17Hmm why do they need to raise so much cash every 9 months? Also does anyone here use them and have any thoughts about their product?
I don't even know why they need so much money for what they do. Based on their website, they solve the following problems: - a central schema registery. Even if that's something you actually want, it's not a problem that requires $93M to solve, or a commercial company to operate - communicating schema changes primarily via human-oriented sources like handwritten documentation on emails. I mean sure, if you are a maso…
I do agree with what you're saying from my perspective as an average swe that doesn't do anything highly specialized...
I wonder though, what would the workflows look like for a swe, product, ops person even, where schema changes get passed around and edited so much, (kind of making some assumptions here, comparing central schema registry to crm use cases), that this would be necessary...
Wonder what the shape of the problem looks like...
Re: Buf raises $93M to deprecate REST/JSON
#18Hmm why do they need to raise so much cash every 9 months? Also does anyone here use them and have any thoughts about their product?
Well, they say the best time to take investment is when you don't need it. If you wait until you need it then the terms will be worse. If investors are offering you money when you don't need it, it may be the best time to accept it.
The sequence of raises here look like a fairly normal sequence for a growing startup, except that they happened much closer together than would be typical. The terms aren't shown but assuming they are in line with a typical sequence then this is a great outcome for buf as it gives them lots of room to build their vision without needing to stress over money for a while.
> Also does anyone here use them and have any thoughts about their product?
FWIW, long ago I was the maintainer of Protobuf at Google, including putting together the first open source release. I like what buf is doing -- enough that, full disclosure, I made an angel investment in their seed round.
There's a huge amount of room for better tooling around Protobuf. Binary and strongly-typed protocols require strong tooling to be usable, but with tooling they can be much better than dynamic and text-based approaches. Like, the fact that the protocol is binary shouldn't make it any harder for a human to read it, because your tools should decode it for you on-demand as easily as you could `cat` a text file. Protobuf historically has had sort of the bare minimum tooling and required a lot of ad hoc copying proto files around between projects to get anywhere, which was a pain. A registry seems like the right first step to making things easier, but I'm really excited about what can be done after that... once you have strong type information, you can have tools to dynamically explore APIs, trace communications, etc.