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

131–135 of 135 posts

Re: Replacing Protobuf with Rust

#131

Post by gorset »

7e wrote: post #128
kentonv wrote: post #124

Earlier quoted context omitted.

Protobuf has far better ergonomics than ASN.1. ASN.1 is an overcomplicated design-by-committee mess. Backwards compatibility in particular is much harder.

I don't doubt your experience, but with X.509 having evolved substantially, and ASN.1 on billions (if not tens of billions) of devices, in practice it seems OK. And it was formally verified early.

One of the advantages of of protobuf I never see anyone highlight is how neat and well-designed the wireformat is, in terms of backward/forward compatibility and lowlevel stuff you can do with it. Very useful when building big and demanding systems over time.

For high performance and critical stuff, SBE is much more suitable, but it doesn't have as good of a schema evolution story as protobuf.

Re: Replacing Protobuf with Rust

#134

Post by koverstreet »

tialaramex wrote: post #36
koverstreet wrote: post #24

Earlier quoted context omitted.

I haven't been following become/TCO in Rust - but what I've usually seen is TCO getting flipped off because it interferes with backtraces and debugging. So I think there's value in providing it as an explicit opt-in; that way when you're reading the code, you know to account for it when you're looking at backtraces. Additionally, if you're relying on TCO it might be a major bug if the compiler isn't able to apply it…

In a language like Rust where local variables are explicitly destroyed when scope ends a naive TCO is very annoying and `become` also helps fix that. Suppose I have a recursive function f(n: u8) where f(0) is 0 and otherwise f(n) is n * bar(n) + f(n-1) I might well write that with a local temporary to calculate bar(n) and then we do the sum, but this would inhibit TCO because that temporary should exist after we did…

Yep, makes sense. More advanced type systems inherently add wrinkles for TCO.

Re: Replacing Protobuf with Rust

#135

Post by yencabulator »

formerly_proven wrote: post #73
logicchains wrote: post #58

Earlier quoted context omitted.

> they had to use a Rust-to-C binding library, that uses Protobuf for portability reasons. That sounds like a performance nightmare, putting Protobuf of all things between the language and Postgres, I'm surprised such a library ever got popular.

> I'm surprised such a library ever got popular. Because it is not popular. pg_query (TFA) has ~1 million downloads, the postgres crate has 11 million downloads and the related tokio-postgres crate has over 33 million downloads. The two postgres crates currently see around 50x as much traffic as the (special-purpose) crate from the article. edit: There is also pq-sys with over 12 million downloads, used by diesel, an…

Notably though, I believe neither tokio nor tokio-postgres parse SQL queries, they just pass them on the wire to the server. Generally the client side doesn't need to parse the query.

https://crates.io/crates/sqlparser has 48 million downloads, though. It's not exactly 100% compatible (yet!) but it's pretty darn great.

Post reply on HN