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.

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.

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]".

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

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

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.

In my experience capn proto is much less ergonomic.

I mean, cap'n'proto is written by the same person who created protobuf, so they are legit (and that somewhat jokish claim is simply that it requires no parsing).

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

Yet they've yet to release their internal optimisation that allows zero-copying string-type fields.

Type safety. The contract is the law instead of a suggestion like JSON.

Having a way to describe your whole API and generate bindings is a godsend. Yes, it can be done with JSON and OpenApi, yet it’s not mandatory.

Well, protobuf allows to generate easy to use code for parsing defined data and service stubs for many languages and is one of the faster and less bandwidth wasting options

It's not just about traffic. IoT devices (or any other low-powered devices for that matter) also like protobuf because of its comparatively high efficiency.

In most languages protobuf is eaiser because it generates the boilerplate. And protobuf is cross language so even if you are working in javascript where json is native protobuf is still faster because the other side can be whatever and you are not spending their time parsing.

Protobuf is fantastic because it separates the definition from the language. When you make changes, you recompile your definitions to native code and you can be sure it will stay compatible with other languages and implementations.

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)

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

I loved, every clickbait title should come with a tldr just like this one.