Live data from Hacker News

Replacing Protobuf with Rust

pgdog.dev

1–10 of 135 posts

Re: Replacing Protobuf with Rust

#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.

Re: Replacing Protobuf with Rust

#3
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.

Re: Replacing Protobuf with Rust

#4
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.

Correct, this has very little to do with Rust. But it wouldn't have made the front page without it.

Re: Replacing Protobuf with Rust

#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.

Re: Replacing Protobuf with Rust

#6
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.

Yes you are absolutely right. The article even outright admits that Rust had nothing to do with it. From the article:

> Protobuf is fast, but not using Protobuf is faster.

The blog post reads like an unserious attempt to repeat a Rust meme.

Re: Replacing Protobuf with Rust

#7
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.

I was equally confused by the headline.

I wonder if it's just poorly worded and they meant to say something like "Replacing Protobuf with some native calls [in Rust]".

Re: Replacing Protobuf with Rust

#8
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.

[deleted]

Re: Replacing Protobuf with Rust

#10
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.

It's devbait, not many of us can resist bikeshedding about the title which obviously doesn't accurately reflect the article contents. And the article contents are self-aware enough to admit this to itself too, yet the title remains.
Post reply on HN