The State of Rust Ecosystem 2025 | The RustRover Blog

Based on findings from the JetBrains Developer Ecosystem Survey Report 2025, The State of Rust 2025 offers a detailed look at how the Rust ecosystem is evolving – how developers use Rust today, which

The Ring Around the Rosie: Upgrading Next.js on RISC-V from 13.5.6 to 14.2.35 | Bruno Verachten

Three attempts. Two hours. One Cargo.toml patch. I've been running Next.js on a Banana Pi F3 (RISC-V hardware) since November. My SWC build for 13.5.6 worked fine with --no-default-features to skip the ring crate. Then Dependabot dropped PRs bumping to 14.2.35. First thought: cross-compile on x86_64. Faster than building on the Pi, right? Wrong. The ring crate's build script panics when it sees riscv64 as the target. No hand-written assembly for the architecture means no build. Cross-compilation doesn't help. Second thought: patch ring to 0.17, which has riscv64 support. Cargo said no. rustls 0.20.9 pins to ring ^0.16. Semver rules block 0.17. Third thought: just rebuild natively like before. Same error. Turns out Next.js 14.x changed how TLS gets configured. It's no longer a default feature you can disable. It's a target-specific dependency baked into the build. The fix? Windows ARM64 already uses native-tls instead of rustls-tls for similar reasons. I added riscv64 to that list. Three lines in Cargo.toml. 130 minutes of build time. Both App Router and Pages Router tests pass. Bonus: Next.js 14.x already includes riscv64 in the architecture loader. Someone at Vercel added it. The only missing piece was the binary itself. The patch is on GitHub. If you're building Next.js on unconventional hardware, native-tls might save you from the ring dependency chain. #NextJS #RISCV #Rust #OpenSource #WebDevelopment #SWC #devEco‍

The Old Dog Learns a New Trick: Cross-Compiling Tauri CLI for RISC-V | Bruno Verachten

The Old Dog Learns a New Trick: A Lesson in Technical Humility After 12 years of cross-compiling for exotic architectures (ARM32 since 2013, unofficial Node.js builds, Docker on RISC-V hardware) I thought I knew the landscape. Strong opinions, formed over a decade of wrestling with toolchains and sysroots. Then a Tauri maintainer left a comment on my PR: "Have you considered cross?" Cross-rs? I'd never heard of it. Let me say that again: twelve years of experience, and I'd never encountered a tool that's been solving these exact problems since 2016. Nine years of development. Excellent RISC-V support. Pre-built Docker containers with toolchains already configured. The results were humbling: • QEMU emulation: 6+ hours (killed) • Native RISC-V (Banana Pi F3): 63 minutes • cross-rs on x64: 4 minutes 27 seconds 14x faster than native hardware. 90x faster than emulation. Same code, same binary output. Here's the uncomfortable truth: I had opinions about cross-compilation. Those opinions weren't wrong (cross-compiling WebKit apps IS a nightmare). But I was solving the wrong problem. Tauri CLI doesn't need WebKit; it's just a build orchestrator. This is the curse of experience: you learn patterns that work, and you stop exploring alternatives. "I know how to do this" becomes "I know how it's done" becomes "this is how it's done." Except sometimes a tool comes along that makes your carefully accumulated knowledge... not obsolete, but certainly less essential. The gray hairs from the ARM32 era taught me A way. Not THE way. Lesson learned: Ask before assuming. A decade of experience doesn't mean you've seen everything. That's not embarrassing, that's the job. PR submitted: https://lnkd.in/eESe_khN Tool that changed everything: https://lnkd.in/e_BbXTCf #RustLang #RISCV #CrossCompilation #OpenSource #Tauri #DevOps #devEco #TechnicalLeadership #LessonsLearned

Adding RISC-V Support to Armbian Imager: A Tale of QEMU, Tauri, and Deja Vu | Bruno Verachten

Adding RISC-V Support to Armbian Imager: When "Straightforward" Becomes a 6-Hour Build I wanted to contribute RISC-V support to Armbian's new Imager app (a Tauri desktop app). Adding a seventh platform to an existing six-platform build seemed straightforward. Famous last words. The journey: 1. WebKit2GTK for RISC-V? Only in Debian trixie (now stable, good timing) 2. NodeSource doesn't support RISC-V, but Debian's native nodejs package works fine 3. The real problem: compiling tauri-cli under QEMU emulation. 600+ Rust crates. After 3 hours I killed the build. Estimated total: 6-8 hours. For context, the same build takes 2 minutes on native x64. My workaround: a pre-built Docker image with tauri-cli already compiled. Suffer once, then subsequent builds drop to 10-20 minutes. But the real fix? Go upstream. Tauri doesn't ship RISC-V binaries yet. If they did, the entire ecosystem would benefit. That's the next step: contribute RISC-V support to Tauri's release workflow. This feels exactly like ARM32 in 2013. I spent that era trying to get docker-compose and RethinkDB working on Raspberry Pi. Same struggles, same patterns. The ecosystem catches up eventually. The code works. The build works. It's just slow. For now. #RISCV #OpenSource #Tauri #Armbian #CrossPlatform #Rust #devEco

BuildKit for RISC-V64: When Your Package Works But Your Container Doesn’t | Bruno Verachten

I shipped BuildKit for RISC-V64 two days ago. The workflows were green, packages built successfully, documentation looked thorough. Then users tried to actually use it. The container crash-looped immediately. "No worker found." Turns out "successful compilation" and "functional deployment" are very different things. The problems: - Missing runc binary meant OCI worker couldn't initialize (BuildKit needs at least one worker to run) - ENTRYPOINT/CMD split was wrong, so Docker Buildx was unable to pass runtime arguments - CI tests hung indefinitely when buildkitd tried to initialize workers without proper privileges - Cached GHCR credentials caused false "access denied" errors Three PRs later, the container works. But here's what I learned: - Testing individual components isn't enough. You need to test how components integrate with the systems that actually use them. It's not enough to verify the car starts; you need to verify it drives. - Always add timeouts. Even commands that "should never hang" will eventually hang. - Use your own packages consistently. Mixing Debian's runc 1.1.12 with our runc 1.3.0 builds created unnecessary version complexity. - Document the WHY, not just the WHAT. Explain when to use container images vs. APT packages. Users need context, not just instructions. The iceberg metaphor fits perfectly: visible success hiding more profound integration problems. Post-deployment debugging is where the real work happens. #BuildKit #RISCV64 #Docker #DevOps #Debugging #ContainerTechnology #LessonsLearned #PostDeployment #devEco

Release BuildKit v0.26.2 for RISC-V64 · gounthar/docker-for-riscv64

Automated build of BuildKit for RISC-V64 BuildKit Version: v0.26.2 Build Date: 2025-12-09 Architecture: riscv64 What is BuildKit? BuildKit is a toolkit for converting source code to build artifacts...

The One-Line Patch That Unlocked Next.js on RISC-V: A Detective Story

After days of wrestling with Babel fallbacks and WASM workarounds, I discovered that Next.js’s failure to recognize riscv64 wasn’t a missing binary problem - it was a simple oversight in the platform detection code.

Building Next.js SWC from Source for RISC-V: A Journey Through the ring Dependency Maze

Picture this: You’ve got Next.js running on riscv64 architecture, but it’s painfully slow because you’re stuck using Babel instead of the blazing-fast SWC compiler.

GitHub - gounthar/openscad: OpenSCAD - The Programmers Solid 3D CAD Modeller

OpenSCAD - The Programmers Solid 3D CAD Modeller - GitHub - gounthar/openscad: OpenSCAD - The Programmers Solid 3D CAD Modeller

Numerique.gouv.fr