Kang Seonghoon ships libbeef, a Rust-native port of Bellard's libbf

Why it matters

libbeef gives Rust developers a new path to arbitrary-precision floating point without a C numerical stack, trading some mature-library speed for portability, license simplicity and build control.

Kang Seonghoon released libbeef 0.1.0 on July 5th, bringing Fabrice Bellard's libbf arbitrary-precision floating-point library into Rust as a same-day crate with a deliberately small surface: pure Rust, MIT license, no_std support with alloc, and no dependencies in the default build.

Kang is a known Rust infrastructure contributor rather than a startup founder selling a hosted product. His GitHub profile lists him in the Republic of Korea with 370 followers. The relevant context is his prior work: he is attached to Chrono, the Rust date and time library with 3.9k stars, and rust-encoding, a character encoding library with 288 stars. That makes libbeef less of a weekend wrapper and more of a maintainer's attempt to fill a specific systems-programming gap: arbitrary-precision floats without pulling a C numerical stack into the build.

The timing is current. The commit history shows three commits on July 5th, including the initial implementation note ("binary ops are complete, decimal ops work") and a final "Release 0.1.0 to crates.io." The tag page lists v0.1.0 on July 5th, and docs.rs shows libbeef 0.1.0 published the same date.

What Kang ported

libbeef translates Bellard's libbf, a C library for arbitrary-precision floating-point numbers. The libbeef README describes the crate as implementing full IEEE 754 semantics (signed zeros, NaN, infinities, configurable exponent width, subnormals, all five rounding modes and status flags) and including transcendental functions: exp, log, pow, sin, cos, tan, atan, atan2, asin and acos.

Kang's Rust version keeps the same numerical ambition. The README says the crate also provides decimal floating point via a BigDecimal type with independent base-10 arithmetic. The public docs describe two main value types, BigFloat (binary) and BigDecimal (decimal), with type wrappers like Float<formats::Binary128> and Decimal<F> that bind a value to a compile-time format so operations apply precision and rounding automatically. Rust's type system becomes part of the numerical contract.

The crate metadata in Cargo.toml names Kang as author, sets version 0.1.0, uses the 2021 Rust edition, and applies the MIT license.

Why pure Rust matters here

The obvious alternative in Rust is not to rewrite the math. It is to bind to mature C libraries through crates such as rug, which uses GMP and MPFR underneath. That gives developers a battle-tested stack and, in many cases, better raw performance. It also brings a C compiler, system libraries or vendored native builds, build scripts, target probing, and licensing review into projects that may be trying to stay Rust-only.

Kang frames libbeef around the situations where that trade is painful: WebAssembly, embedded targets, cross-compilation, and supply-chain-sensitive builds. The README positions libbeef as building on targets rustc supports (including WASM and embedded), with no build.rs, and no_std compatibility when allocation is available.

That is the bet. Developers already have faster and older numerical libraries. libbeef is aimed at teams that want Bellard-style arbitrary-precision floating point inside a Rust build graph that stays boring during cross-compilation.

The same pattern has been showing up across lower-level open-source work. RuntimeWire recently covered Ekin Ertac's Phargo work on an AI-built PHP engine in Rust, where the public benchmark was upstream PHP compatibility rather than a launch metric. We also covered Vincenzo's NanoEuler, a C and CUDA GPT-2-scale training stack whose value was educational control over the layers most teams outsource. libbeef belongs to that same builder instinct: own the hard substrate, even when the market would rather package a service.

The benchmark claims need the right label

Kang includes a detailed benchmark report, measured on July 5th on an Apple M4 with 32 GiB of RAM, macOS 26.5, rustc 1.96.1 in release mode, Bellard's C libbf version 2025-06-03, rug 1.30.0, num-bigint 0.4.7, and malachite-nz 0.4.22. The report measures nanoseconds per 64-bit limb per operation, with lower being better.

The results are author-produced, so they should be read as reproducible project data rather than independent performance certification. Still, the report is more useful than a vague "fast" claim because it states hardware, versions, methodology and caveats. Its table lists libbeef's per-limb timings of roughly 100 ns for multiplication at 300,000 bits (about 84 ns at 30,000 bits), about 659 ns for division at 300,000 bits (about 515 ns at 30,000 bits), and about 597 ns for square root at 300,000 bits. The README says MPFR remains ahead by roughly 3x to 5x on several transcendental functions. The benchmark report also calls out a decimal limitation: libbeef's decimal path routes through conversion machinery rather than native base-10 kernels, and reaching libbf-level decimal performance would require porting those native decimal kernels.

That candor is useful. It tells developers when libbeef is a fit and when it is not. If the bottleneck is maximum throughput at very large precision, rug and the GMP/MPFR stack remain the safer performance bet. If the bottleneck is a Rust-native dependency story across WASM, embedded or cross-compiled targets, libbeef now gives the Rust community a new primitive to test.

Bellard context gives the port its weight

Fabrice Bellard is central context because libbeef inherits its design target from his library. Amarisoft lists Bellard as co-founder and CTO, says he studied at Ecole Polytechnique and Telecom Paris, and credits him with FFmpeg and QEMU work. Bellard's libbf page shows the upstream library received a June 3rd, 2025 update with the BFCalc calculator application.

Kang has not published a broader origin story for libbeef beyond the README's direct statement that it is a Rust translation of libbf. That is enough to understand the first release: libbeef is a maintainer-led port of a compact numerical library with a clear technical constraint. It does not disclose funding, a commercial entity, customers, sponsors or a roadmap beyond the code and documentation now online.

The open question is adoption. At publication, the GitHub repository showed a tiny early audience, no forks, no open issues, no pull requests and 100% Rust code. That is normal for a same-day numerical crate. The harder test will come from the first real downstream users who try to run it under WASM, embedded targets, license-sensitive environments, and Rust-only build systems where C linkage has been the reason to avoid arbitrary-precision floating point entirely.