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

Replacing Protobuf with Rust

pgdog.dev

Post reply on HN
Print view View original

11–20 of 135 posts

Re: Replacing Protobuf with Rust

#11

Post by embedding-shape »

IshKebab wrote: post #5

I vaguely recall that there's a Rust macro to automatically convert recursive functions to iterative. But I would just increase the stack size limit if it ever becomes a problem. As far as I know the only reason it is so small is because of address space exhaustion which only affects 32-bit systems.

> I vaguely recall that there's a Rust macro to automatically convert recursive functions to iterative.

Isn't that just TCO or similar? Usually a part of the compiler/core of the language itself, AFAIK.

Re: Replacing Protobuf with Rust

#12

Post by win311fwg »

nottorp wrote: post #2

Are they sure it's because Rust? Perhaps if they rewrite Protobuf in Rust it will be as slow as the current implementation. They changed the persistence system completely. Looks like from a generic solution to something specific to what they're carrying across the wire. They could have done it in Lua and it would have been 3x faster.

The title would suggest that it was already written in Rust; that it was the rewrite in Go that brought five times faster.

Re: Replacing Protobuf with Rust

#13

Post by nindalf »

yodacola wrote: post #9

FlatBuffers are already faster than that. But that's not why we choose Protobuf. It's because a megacorp maintains it.

You're saying we choose Protobufs [1] because Google maintains it but not FlatBuffers [2]?

[1] - https://github.com/protocolbuffers/protobuf: Google's data interchange format

[2] - https://github.com/google/flatbuffers: Also maintained by Google

Re: Replacing Protobuf with Rust

#14

Post by desiderantes »

consp wrote: post #3
nottorp wrote: post #2

Are they sure it's because Rust? Perhaps if they rewrite Protobuf in Rust it will be as slow as the current implementation. They changed the persistence system completely. Looks like from a generic solution to something specific to what they're carrying across the wire. They could have done it in Lua and it would have been 3x faster.

If they made the headline something on the line of "replacing protobuf with a native, optimized implementation" would not get the same attention as putting rust in the title to attract the everything-in-rust-is-better crowd.

That never happens. Instead, it always attracts the opposite group, the Rust complainers, where they go and complain about how "the everything-in-rust-is-better crowd created yet another fake headline to pretend that Rust is the panacea". Which results in a lot of engagement. Old ragebait trick.

Re: Replacing Protobuf with Rust

#15

Post by jeroenhd »

IshKebab wrote: post #5

I vaguely recall that there's a Rust macro to automatically convert recursive functions to iterative. But I would just increase the stack size limit if it ever becomes a problem. As far as I know the only reason it is so small is because of address space exhaustion which only affects 32-bit systems.

Explicit tail call optimization is in the works but I don't think it's available in stable jut yet.

The `become` keyword has already been reserved and work continues to happen (https://github.com/rust-lang/rust/issues/112788). If you enable #![feature(explicit_tail_calls)] you can already use the feature in the nightly compiler: https://play.rust-lang.org/?version=nightly&mode=debug&editi...

(Note that enabling release mode on that link will have the compiler pre-calculate the result so you need to put it to debug mode if you want to see the assembly this generates)

Re: Replacing Protobuf with Rust

#17

Post by rafaelmn »

nindalf wrote: post #13
yodacola wrote: post #9

FlatBuffers are already faster than that. But that's not why we choose Protobuf. It's because a megacorp maintains it.

You're saying we choose Protobufs [1] because Google maintains it but not FlatBuffers [2]? [1] - https://github.com/protocolbuffers/protobuf : Google's data interchange format [2] - https://github.com/google/flatbuffers : Also maintained by Google

I get the OP is off base with his remark - but at the same time maintained by Google means shit in practice.

AFAIK they have a bunch of production infra on protobuff/gRPC - not so sure about flatbufferrs which came out of the game dev side - that's the difference maker to me - which project is actually rooted in.

Re: Replacing Protobuf with Rust

#19

Post by dewey »

rafaelmn wrote: post #17
nindalf wrote: post #13

Earlier quoted context omitted.

You're saying we choose Protobufs [1] because Google maintains it but not FlatBuffers [2]? [1] - https://github.com/protocolbuffers/protobuf : Google's data interchange format [2] - https://github.com/google/flatbuffers : Also maintained by Google

I get the OP is off base with his remark - but at the same time maintained by Google means shit in practice. AFAIK they have a bunch of production infra on protobuff/gRPC - not so sure about flatbufferrs which came out of the game dev side - that's the difference maker to me - which project is actually rooted in.

> but at the same time maintained by Google means shit in practice.

If you worked on Go projects that import Google protobuf / grpc / Kubernetes client libraries you are often reminded of that fact.

Post reply on HN