Hello Rustaceans!

It's glad to be here releasing bincode-next again, this time the v3 stabilization release!
Because our release pipeline is tightly bound with GitHub OIDC and signed tags, due to some problems in our release workflows, we "wasted“ some version numbers and directly start the v3 generation from v3.1.1.

The v3.1.1 release (I'll call it 'this release' in the rest of this post) mainly stabilized the bit packing feature, the zero-copy feature, the CBOR format, the static-size feature, and the schema fingerprint feature. But the async-fiber feature is experimental till this release because it contains too many unsafe rust and even assembly. But anyway, in practice, I believe that the async-fiber feature is ready to be used anyway, as it is well tested through our TortureReader based fuzzer. But our team member thought it would be better to keep it experimental, so I will announce it as experimental anyway.
Due to some bug fix and other functionality improvements some performance regression slightly takes place comparing to v3.0.0-rc.1, and we are on the way of fixing them.

The v3 stabilization release comes with the same MSRV promise as we have said before (latest stable -3), but as we do not need such high MSRV till now, so we currently set it at 1.90.0 which is the version where a LLVM bug is fixed. But this do not mean the MSRV will stay so: as we have said in earlier posts, only changing the MSRV policy is thought to be breaking.
But this release also comes along with new promises, which is the promise of stabilizing the bincode data format. We've have regression tests for this, and any future breaking of the data format will be seen as a breaking change (and don't forget we also have the optional fingerprint to hash your configs!).
Also, surprisingly the main API of v3 seems to me, from the high level API perspective, unchanged from the original bincode v2 apis, so users can migrate smoothly just using package = "bincode-next" in their Cargo.toml. We also kept the serde compatibility and do some small performance upgrade.

Below are the introduction of the new functionalities and the design philosophy, it might be a little bit minimal as without LLM a human could not write that much, but I thought they are meaningful so, they will appear here. To avoid being thought as rage-baiting we will make no comparison here.

Bit Packing
Core Philosophy: Explicit is better then Implicit; A serialization library shall not be in change of compression algorithms.
We mainly use declarative APIs like, for example, like #[bincode(bits = 1)] with compile time assertions to control the encoding/decoding behavior and keep the KISS principle.

Zero Copy
Core Philosophy: Explicit is better then Implicit; Rust native is better: make full use of the compilers functionalities.
We take the same step as FlatBuffers or Cap'n Proto, but rust native. Friendly to IPC and Microservice.
The API is more explicit:
ZeroBuilder::new() -> builder.reserve::<T>() -> build_to_target -> builder.finish()
Also security: full MIRI compliance, clippy compliance, hundreds of hours of fuzzing. These will be addressed in details later in this post

Static Size & Fingerprint & CBOR Support
Core Philosophy: Well, not too many things here... Just compile time checks first; bit masking first.
Mostly these are for no-std environments and more standard environments. You can just using them by opening an optional feature (for static-size) or just config::standard().with_fingerprint() config::standard().with_cbor_format(). What is noticeable is that we all provide derive macros for these. And other specials? There are many, but well, not a thing of this post to keep it short.

And about the experimental async-fiber issue: it is already discussed in details here https://users.rust-lang.org/t/discussion-on-synchronous-crate-concurrency-refactor-using-stackful-coroutines-model-in-rust/139246/9
But personally I would recommend using dtact + sync apis of bincode-next, which is noticeably faster according to the bench, and as dtact is very lite it do not effect too much if you mainly uses tokio. Dtact Official Website, Dtact repository, and former release posts.

Performance

Unlike postcard which is designed for embedding environments, our priority is: security > CPU time > developer time > memory usage > code size
There are some regressions compared with v3.0.0-rc.1, and we are actively try to fix these regressions.
CI/CD run links:bump: v3.1.1 · Apich-Organization/bincode@732e8c8 · GitHub
bench report links: Bench Results of bincode-next-next

CBOR Encoding & Decoding

Complex World Benchmarks

Baseline: bincode-next (fixed) for encoding, bincode-next (varint) for decoding.

Postcard Comparison

Security

Myself has been once on the front line of cyber security and after a digital identity wash to permanently left there go back to physics and also comes to our inclusive rust community. And we surely takes security seriously.
Full full MIRI compliance, clippy compliance, cross platform testing, property based testing using proptest, and continuous fuzzing (Continuous Fuzzing · Workflow runs · Apich-Organization/bincode · GitHub) are promised by our CI/CD pipeline. We fully enforced immutable releases, trusted publishing, CA/Web3 timestamps, and GPG signed signature on every commits. We also participate in the OpenSSF open source supply chain security standards, reaching score 8.6 (OpenSSF scorecard report) and best practices (BadgeApp).
More links about security could be found below in the Links section.

Useful Links

Discord Server: Apich Organization
Contact E-mail: info@apich.org
Security Reporting: security@apich.org
Organization Homepage: https://apich.org/
Security Team Homepage: https://security.apich.org/
Project Homepage: https://bincode-next.apich.org/
GitHub: GitHub - Apich-Organization/bincode: Bincode-next: The next official rust implementation of bincode · GitHub

PS: It has been more then half a year since the original bincode gone dark due to really sad reasons and we started bincode-next, and well, but maintaining an open source infrastructure are things of decades of work. Although it seems that we are a little bit too heavily branded, in the end, we are just a group of developers that comes from the community and requires community help. And we really appreciate any kinds of contribution from the community.

1 post - 1 participant

Read full topic