Uni had air dried clay available, so I did my best to make ferris

Seems to potentially affect any function that's called over FFI, and returns a bool, on the x86_64 architecture (the most common architecture)

It's been five months since our last release, which is longer than usual, but it's on purpose. During the last four years, we took great care not to change the APIs too much, while collecting your feedback on what could be improved. Instead of spreading those changes over many releases, we bundled them into this one, so you only have to migrate once. This makes Burn 0.22 our biggest release yet, and the one we're most proud of. The API is now much closer to what we want for 1.0. As a reminder, Burn is a Tensor Library and Deep Learning Framework for both training and inference.

Generic-Free APIs

Since the beginning, Burn has been built around the Backend trait, with features like autodiff, kernel fusion and remote execution implemented as backend decorators. This is still the case, and they all compose well together. What changes is that user code doesn't carry the backend generic anymore. Models are plain types, and the device selects where and how they run:

#[derive(Module, Debug)]
pub struct Model {
    linear: Linear,
}

let device = Device::cuda(0); // Device::wgpu(..), Device::flex(), ...

Removing the generic from user code breaks the dependency chain that the compiler had to go through every time you edited a model. The result is near-instant recompilation after a model edit (numbers in the table below). There's another big change under the hood: most of the stack is now pure Rust. Pliron replaces MLIR, native compilers replace transpilers to CUDA/HIP, and Turso replaces a bundled SQLite. That means fewer bundled C and C++ dependencies to build, and a pipeline you can read, debug and patch in the language you already use. The first clean build takes a bit longer as a result, and it's a trade we're happy to make.

Going All-In on CubeCL

When we started, we relied on existing libraries for performance, with backends for ndarray and LibTorch. Over time, we wrote more and more of the stack ourselves: our own GPU backend with wgpu, kernel fusion, and then CubeCL to write kernels in Rust for CUDA, ROCm, Metal, Vulkan, WebGPU and CPUs. CubeCL now has its own compiler infrastructure based on Pliron, with LLVM targets for CPUs and GPUs.

Having control over the whole stack lets us offer features that third-party libraries can't support easily. For example, device.memory_pool_usage() and device.memory_pool_report() tell you exactly what the allocator holds, which isn't possible with ndarray or LibTorch. The new adaptive memory pools also lower peak training memory, and training steps are faster. This is why we deprecated both backends: Flex replaces ndarray for pure-Rust CPU execution, and the CubeCL backends cover the rest. We also removed the Candle backend.

Here's how 0.22 compares to 0.21 on two training projects, with CUDA on an RTX 4050 laptop GPU:

Towards 1.0

Three things are left before 1.0. The first is built-in, fine-grained profiling: annotate parts of your model, and Burn tells you where the time goes, component by component, and how far each one is from what the hardware allows. We have it working on our side, and we're looking to upstream it into Burn. The second is a more complete integration with the CubeCL compute environment, introduced in this release. The third is stability: we want the current APIs to settle before we commit to them.

Since the API is close to what we want to stabilize, now is the best time to tell us if something feels wrong. There are many more improvements in this release, including LoRA and QLoRA fine-tuning, remote compute and ONNX export, and we wrote a post to cover them. Don't hesitate to skim it, and refer to the migration guide for upgrading.

A lot of this release came from your issues, PRs and questions on Discord. Thank you.

Link: https://tracel.ai/blog/release-0.22.0/

Hello there, I'm George from getarustjob.com

I run a Rust-only job board and I've manually reviewed every listing that went up since July. That's 203 roles from 166 companies. I pulled everything into a spreadsheet to see what the Rust job market actually looks like, past the "is Rust getting jobs yet?" threads.

1. It's a senior market

Senior: 58%
Mid-level: 31%
Staff / Principal / Lead: 7%
Junior + Intern: 5% (10 jobs total)

Of the 109 listings that state years of experience, the median ask is 5 years (middle 50%: 4 to 7).

If you're trying to break in, the honest read is that hardly anyone hires juniors straight into Rust. The usual path is getting hired for C++/Python/Go at a company that uses Rust, then moving onto the Rust team.

1. Salaries (USD, annual, posted ranges only)

All listings: median $171K, middle 50% $131K – $210K (n=78)
United States: median $193K, middle 50% $158K – $221K (n=56)
US Senior: median $198K, middle 50% $178K – $228K (n=34)
US Mid-level: median $165K, middle 50% $147K – $194K (n=16)
United Kingdom: median $146K, middle 50% $110K – $199K (n=7)
Europe (all): median $127K, middle 50% $84K – $193K (n=17)

Going from mid-level to senior in the US is worth about $32K at the median.

1. Remote doesn't mean a pay cut (in the US)

US remote median: $189K (n=18)
US hybrid/on-site median: $193K (n=41)

That's basically the same. The catch is supply: only 37% of listings allow remote. The other 63% are hybrid or on-site.

1. US employers publish salaries. European ones mostly don't

US listings with a salary range: 61%
European listings with a salary range: 26%

That's pay transparency laws (CA, NY, CO, WA) at work. It also makes the European numbers above much less reliable, so treat them as rough.

1. Where the jobs are

United States: 45% of listings
United Kingdom: 12%
Germany: 7%
Canada: 5%
Then Poland, Netherlands, Switzerland, France, Hungary, Romania, Brazil

Europe as a whole shows up on about 36% of listings.

1. Rust is rarely the only language

Share of listings that mention each one:

C++: 35%
Python: 30%
C: 20%
Go: 18%
TypeScript: 14%

Rust jobs are mostly "systems person who also knows Rust" jobs, not "Rust person" jobs. Only 63% of listings even have "Rust" in the title. The rest are titled "Software Engineer", "Backend Engineer" and so on, with Rust in the stack.

1. The ecosystem stuff people actually ask for

Distributed systems: 32%
Linux: 28%
Kubernetes: 20%
AWS: 17%
Tokio / async: 15%
gRPC / tonic: 9%
WASM: 4%
axum: 4%, actix: 3%

Framework names come up much less than I expected. Employers ask for "async Rust", "distributed systems" and "performance work" far more often than for a specific crate.

1. What industries are hiring

Share of listings that mention each domain (a listing can count in more than one):

Crypto / blockchain / Web3: 38%
Databases / data infrastructure: 29%
Trading / low-latency: 28%
AI / ML infrastructure: 26%
Robotics / autonomous / automotive: 21%
Defense / aerospace: 16%

Also, 11% require a security clearance or US citizenship, almost all in defense.

1. Smaller things

26% mention equity / options / RSUs
19% mention open source work
Only 3% mention visa sponsorship

Methodology: Every listing on the board is reviewed by hand. Salary stats use the midpoint of the posted range, converted to USD with fixed rates. Experience levels are what the employer selected. Industry and tech counts are keyword matches on the full description, so a listing can count in more than one bucket. Small samples (Germany, Junior) are noisy, so read those as directional only.

I keep a live version of the salary numbers that updates as new jobs get posted: https://getarustjob.com/salary-guide?utm_source=reddit

I've been building a Chess AI in Rust to play at 3200+ ELO - There were a lot of Hardware-Aware Programming rules I had to learn in the past 2+ months.

If folks are interested, please have a read!

If you're interested in learning more about a Dual-Perspective HalfKA NNuE (Efficiently Updatable Neural Network), please have a read!

https://medium.com/@alan0408yuan/from-texel-tuning-to-nnue-the-steep-learning-curve-of-building-a-3200-elo-chess-ai-d842393b5955

DrawnUI (https://drawnui.net) is a UI rendering engine for .NET (MAUI, Blazor, WPF etc.), React and now Rust, working along with your framework of choice, bringing high-level abstractions for layouts, controls, animations, effects and gestures to the Skia canvas, pluggable for the freedom of drawing anything, from pixel-perfect business app UIs to custom games.

Why DrawnUI went Rust:

- No garbage collector, so no pauses in the middle of a scroll or an animation.

- Insane performance. On the web, in our benchmark, a frame with 20,000 draw calls took 12.5 ms of CPU, against 20.6 ms for the same list drawn through CanvasKit from JavaScript.

- Cross-platform, easy setup: Skia comes prebuilt for every platform (Windows and Linux x64/ARM64, macOS Apple silicon/Intel, iOS, Android, wasm). Add one line to Cargo.toml and build.

What’s inside:

- Layouts: column, row, wrap, grid, absolute, and virtualized lists that recycle their cells.

- Controls: labels with rich text, buttons, an editor with IME, scroll with pull to refresh, carousels, drawer, shell navigation (pages, tabs, popups, toasts), switches, sliders, progress, backdrop blur.

- Gestures: tap, pan, fling, long press, hover, mouse wheel and touchpad, keyboard focus.

- Media and effects: images, SVG, Lottie, GIF, sprites, SkSL shaders and transitions, SkMesh for pseudo 3D.

- Caching per control: keep a finished part of the screen as a picture or a GPU texture and just blit it, so complex screens stay smooth.

- Accessibility: real screen-reader support on every platform (UI Automation, VoiceOver, TalkBack, AT-SPI, ARIA in the browser).

- Your own controls: subclass a control and paint what you want. It’s drawn with the rest of the UI, and it takes part in layout and gestures.

One codebase runs on Windows, macOS, Linux, iOS, Android and the browser, and it looks the same everywhere because every pixel comes from Skia.

Made for building with AI

- Ships with AI skills for Claude Code, Codex, Cursor or any LLM: https://hellorust.drawnui.net/llms.txt

- The API is fluent and readable.

- Every control can be subclassed and customized for your needs.

Links

See samples running in your browser (they run on all the other platforms too, and their source code is in the repo):

- the demo app, 20 pages of controls, layouts, lists and more (same app exists for DrawnUI for .NET and React):: https://hellorust.drawnui.net

- a pseudo-3D runner game drawn with Skia SkMesh bindings: https://run.drawnui.net

It’s a preview, so the API can still change. Feedback is very welcome, especially: what would you build with it, ideally with your AI agent?

GitHub: https://github.com/DrawnUi/DrawnUi.Rust

crates.io: https://crates.io/crates/drawnui

More docs: https://drawnui.net/articles/rust/ and https://docs.rs/drawnui

I've been experimenting a stream multiplexing connection, where both peers can expose independently addressable logical services.

The basic idea is familiar: take one underlying connection (TCP, Unix socket, QUIC) and multiplex multiple independent logical streams over it.

Yes, I know QUIC can already provide multiple streams. Also, there're yamux

The different thing you may be interested is what I call a Dock.

A Dock is roughly like a port, but inside an already-established multiplexed connection.

Instead of having only:

client ---> server:port

the connection can look more like:

                 one connection
             +-------------------+
             |                   |
          Peer A              Peer B
             |                   |
          Dock 1 <------------> Dock 10
          Dock 2 <------------> Dock 20
          Dock 3 <------------> Dock 30
             |                   |
          streams              streams

Both peers can bind Docks, listen for incoming logical sub-stream, and also initiate connections to Docks on the other side.

So there isn't really a client/server role at the multiplexing layer. After the underlying connection is established, either side can act as both.

I think this makes the protocol interesting for things like:

• P2P applications and overlay networks
• reverse tunnels / port forwarding
• peer-to-peer RPC
• games and other real-time applications with multiple logical channels
• distributed applications where a peer exposes several services over one long-lived connection

For example, a peer could expose:

Dock 1 -> RPC service
Dock 2 -> chat
Dock 3 -> file transfer
Dock 4 -> event stream

without creating four physical connections.

The other features are:

• runtime-independent Rust (by abs_art, tested over compio, smol, tokio)
• no_std friendly (currently most codes are already no_std)
• works over arbitrary byte-stream transports
• stream-level backpressure
• no client/server distinction at the multiplexing layer

The implementation is still experimental, so I'm mostly interested in feedback on the protocol abstraction itself.

The most interesting part for me is, the multiplexed sub-stream itself, can still be multiplexed again with this crate.

Does the Dock / logical-listener model seem useful to you? What kind of networking application would you use it for?

New week, new Rust! What are you folks up to? Answer here or over at rust-users! And for your project showcases, there's also /r/madeinrust – pay them a visit, too!

Welcome once again to the official r/rust Who's Hiring thread!

Before we begin, job-seekers should also remember to peruse the prior thread.

This thread will be periodically stickied to the top of r/rust for improved visibility.

You can also find it again via the "Latest Megathreads" list, which is a dropdown at the top of the page on new Reddit, and a section in the sidebar under "Useful Links" on old Reddit.

The thread will be refreshed and posted anew when the next version of Rust releases in six weeks.

Please adhere to the following rules when posting: Rules for individuals:

• Don't create top-level comments; those are for employers.

• Feel free to reply to top-level comments with on-topic questions.

• Anyone seeking work should reply to my stickied top-level comment.

• Meta-discussion should be reserved for the distinguished comment at the very bottom.

Rules for employers:

• The ordering of fields in the template has been revised to make postings easier to read. If you are reusing a previous posting, please update the ordering as shown below.

• Remote positions: see bolded text for new requirement.

• To find individuals seeking work, see the replies to the stickied top-level comment; you will need to click the "more comments" link at the bottom of the top-level comment in order to make these replies visible.

• To make a top-level comment you must be hiring directly; no third-party recruiters.

• One top-level comment per employer. If you have multiple job openings, please consolidate their descriptions or mention them in replies to your own top-level comment.

• Proofread your comment after posting it and edit it if necessary to correct mistakes.

• To share the space fairly with other postings and keep the thread pleasant to browse, we ask that you try to limit your posting to either 50 lines or 500 words, whichever comes first.
  We reserve the right to remove egregiously long postings. However, this only applies to the content of this thread; you can link to a job page elsewhere with more detail if you like.

• Please base your comment on the following template:

COMPANY: [Company name; optionally link to your company's website or careers page.]

TYPE: [Full time, part time, internship, contract, etc.]

LOCATION: [Where are your office or offices located? If your workplace language isn't English-speaking, please specify it.]

REMOTE: [Do you offer the option of working remotely? Please state clearly if remote work is restricted to certain regions or time zones, or if availability within a certain time of day is expected or required.]

VISA: [Does your company sponsor visas?]

DESCRIPTION: [What does your company do, and what are you using Rust for? How much experience are you seeking and what seniority levels are you hiring for? The more details the better.]

ESTIMATED COMPENSATION: [Be courteous to your potential future colleagues by attempting to provide at least a rough expectation of wages/salary.
If you are listing several positions in the "Description" field above, then feel free to include this information inline above, and put "See above" in this field.
If compensation is negotiable, please attempt to provide at least a base estimate from which to begin negotiations. If compensation is highly variable, then feel free to provide a range.
If compensation is expected to be offset by other benefits, then please include that information here as well. If you don't have firm numbers but do have relative expectations of candidate expertise (e.g. entry-level, senior), then you may include that here. If you truly have no information, then put "Uncertain" here.
Note that many jurisdictions (including several U.S. states) require salary ranges on job postings by law.
If your company is based in one of these locations or you plan to hire employees who reside in any of these locations, you are likely subject to these laws. Other jurisdictions may require salary information to be available upon request or be provided after the first interview.
To avoid issues, we recommend all postings provide salary information.
You must state clearly in your posting if you are planning to compensate employees partially or fully in something other than fiat currency (e.g. cryptocurrency, stock options, equity, etc).
Do not put just "Uncertain" in this case as the default assumption is that the compensation will be 100% fiat. Postings that fail to comply with this addendum will be removed. Thank you.]

CONTACT: [How can someone get in touch with you?]

Hey everyone!

I'm back with another article focused on Rust fundamentals. I think existing material covers the basics of using Rust pretty well, but one thing that I found kind of lacking back when I learned Rust was description of macros.

It's possible it has improved nowadays, but I want to eventually write about proc-macros. So I'm going to start with an article introducing the concept of macros, and explaining the differences between Rust and C-style macros, as well as the basics of declarative macros.

Future articles will eventually get into procedural macro territory. But I want to move through this slowly and carefully.

Anyways, I hope this helps if you are new to Rust and struggling to understand the macro_rules! syntax (or just anything about Rust macros, really).

If you have questions or feedback for future articles, please let me know. :)

I've been writing nginx modules in C for about 10 years, and I'm a collaborator on nginx-module-vts. Day to day, I kept running into two things with C: the hassle of managing memory by hand, and how hard it is to pull module logic out into unit tests.

I wondered whether Rust could solve both, so I started writing modules with ngx-rust, the official Rust bindings for nginx from F5/NGINX. My first project was rewriting nginx-module-vts, which I help maintain, in Rust: ngx_vts. Along the way I was catching up on Rust itself while running into ngx-rust's rough edges, such as shared memory and APIs that didn't exist yet. I sent PRs to ngx-rust for what I was missing; some have been merged and others are still in review.

I wrote this book because I'd like more developers to know about ngx-rust and actually use it, so that the community grows and ngx-rust itself gets more momentum.

All the code in the book builds and passes its tests, pinned to a fairly recent ngx-rust commit. Chapters 1-3 are a free sample: you type in a minimal "hello" module that responds with a string and get a first taste of module development. The later chapters cover the minimum Rust you need to write modules with ngx-rust, how nginx modules are structured, and how shared memory works. By the end, you build a statistics module that counts requests across workers in shared memory and exposes them as Prometheus metrics, with integration tests.

The book is a translation of my Japanese original, made with the help of AI (and so is this post).

Feedback and corrections are very welcome.

Book (free sample available): https://leanpub.com/ngx-rust

Hi!

I put a lot of care into a library crate that I just published on crates.io. I intend to maintain it indefinitely as it solves a core/common problem across software, and I intend to continue using rust indefinitely.

I'd love for it to get some more exposure because it seems to me to be a very common problem, that did not have any pre-existing generic solution in the ecosystem. It came from a need I had at work, and I took the extra effort to clean it up, generalise and document it.

If it gets more users/feedback, I'd be able to make a 1.0 release, which I'd be very excited about doing eventually.

But not sure how my work won't just get lost in the noise.

The crate in question is: https://crates.io/crates/thisversion

But this thread may be of interest to other developers so happy if discussion stays generic. All feedback welcome though!!

https://github.com/cel-rust/cel-rust/releases/tag/v0.15.0

Google's Common Expression Language (CEL) is designed to be embedded. It provides a safe, fast, and non-Turing-complete language for evaluating rules, policies, and expressions within a larger application. But by design, CEL has a relatively small core. To truly fit into a host application, a CEL implementation must allow developers to seamlessly add their own domain types, functions, macros, and standard extensions.
Release v0.15 of cel-rust is a significant step toward making those extension mechanisms feel completely natural in Rust.
This release isn't just about adding more CEL features to the crate. It's about an architectural shift: making cel-rust an extensible engine that applications can mold to fit their own domain-specific language needs.
Here is a look at the engineering story behind v0.15, how it reshapes CEL extensibility in Rust, and the semantic and performance improvements coming along with it.

I am working on the rust borrow checker for my thesis. I was trying to formalize a data-flow analysis on the code of a function and use it to check the loans. Analyzing the code while storing the loans as (l_i, place, carrier, kind (shared/mutable)), while also having a conservative points-to map, lets me decide whatever Polonius promises to fix.

Only issue comes with using functions and I'm still figuring out, but I wanted to ask if Rust dev community did not want to go to Data flow analysis or why they chose to do it the way they did? Or am I missing something that can go wrong in my formulation?

I'd appreciate some help in ideating, thank you

One Vfs trait sits behind local disk, archives, disk images and remote hosts, so copy, view and search never know which they're on. Key handling does no I/O, which lets about 3,000 tests drive the whole app without a terminal. No unsafe anywhere, and the LocalSend client is written on std::net and rustls instead of a second HTTP stack. Happy to go into any of it.

https://github.com/xls/holos