DiceBear 10.2 - Release Notes #533
FlorianKoerner
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
After Python joined the family in 10.1, version 10.2 adds two more official implementations: DiceBear now speaks Rust 🦀 and Go 🐹
The API is the same as in JavaScript, PHP and Python, and the same seed and style definition produce byte-identical SVGs in all five languages.
🦀 Rust Support
DiceBear is now available as a Rust crate (Rust 1.80+). You need two crates: the core library
dicebear-coreand the avatar style definitionsdicebear-styles, where each style sits behind a feature of the same name.Example:
🐹 Go Support
DiceBear is also available as a Go module (Go 1.23+). Again you need two packages: the core library
github.com/dicebear/dicebear-go/v10and the avatar style definitionsgithub.com/dicebear/styles/v10. The module paths carry the major version, so both are imported with the/v10suffix.Example:
🔍 How do we keep five languages byte-identical?
With five implementations generating the same avatars, a fair question is how we make sure that
seed: "Felix"looks exactly the same everywhere.The first part of the answer: no implementation makes its own decisions. Every library uses the same deterministic random number generator and the same rendering pipeline. Your seed is turned into a number, and that number drives every "random" choice (which hairstyle, which color) in a fixed order. The JavaScript library is the reference, and the other languages follow it step by step.
The second part is a shared test suite. From the JavaScript reference we generate fixture files with a few hundred test cases: expected SVGs for many seed and option combinations, expected random number sequences, color calculations, initials for tricky names, and which style definitions and option values must be rejected as invalid. Every implementation has to reproduce these fixtures byte for byte in CI. If a single character differs, the build fails.
This is harder than it sounds, because programming languages disagree on surprisingly small things, like how to round
-0.5or the last decimal of apow()call. Whenever the test suite catches such a difference, we pin down one behavior and make every language follow it. A few of those fixes landed in this release:pow()at runtime. Math libraries roundpow()slightly differently (even browsers disagree among themselves), which in contrived cases could change contrast-based color ordering. JavaScript output is unchanged, and rendered SVGs were never affected.@in the seed (e.g. an email address) now discard everything from the@onward in all languages, even when the seed contains line breaks.encodeURIComponent, sotoDataUri()is byte-identical across languages.toJson()is now serialized identically everywhere: Rust orderssizebeforetitlelike the others, and Python emits whole numbers as1instead of1.0.💬 Which language next?
DiceBear now speaks five languages, and we'd like to hand the choice of the sixth to you. Ruby, Java, C#, Swift, or something else entirely? Head over to the discussions and tell us which official implementation you want to see next.
This discussion was created from the release DiceBear 10.2 - Release Notes.
Beta Was this translation helpful? Give feedback.
All reactions