rtic VS dfdx

There's also RTIC which is another framework that makes concurrency trivial.

Github here: https://github.com/rtic-rs/rtic

At Telecom Paris, one of the top engineering schools in France, we teach Rust to undergraduate and graduate students who specialize in Embedded Systems. They get to use Rust and RTIC on STM32 based boards, and they also use Embassy for some projects.

If you want something more cutting edge. Try embedded Rust and checkout RTIC. I don't know if it's the real next thing. But i guess it could be fun to try.

RTIC is still going strong, they are working on a 2.0 release at the moment :). There's also now embassy which provides an async runtime (and a ton of other nice things) for embedded as well :)

RTIC - RTOS and task scheduling

That's completely incorrect. The existing ecosystem focuses on web/IO because that's were Async/Await is already being used in other languages so everyone started there. There is significant interest in writing frameworks using async rust in embedded, but the required compiler features for it are still not stable. Check out embassy. Even RTIC has experiments with async.

But neither of them might be usable in you case. Since it looks like you're running bare-metal, a framework like RTIC can give you a initialization function and then pass "static" data to a struct that is shared between all tasks.

FYI, RTFM has been renamed to RTIC

I keep checking the progress on dfdx for this reason. It does what I (and, I assume from context, you) want: Provides static checking of tensor shapes. Which is fantastic. Not quite as much inference as I'd like but I love getting compile-time errors that I forgot to transpose before a matmul.

It depends on the generic_const_exprs feature which is still, to quote, "highly experimental":

https://github.com/rust-lang/rust/issues/76560

Definitely not for production use, but it gives a flavor for where things can head in the medium term, and it's .. it's nice. You could imagine future type support allowing even more inference for some intermediate shapes, of course, but even what it has now is really nice. Like this cute little convnet example:

https://github.com/coreylowman/dfdx/blob/main/examples/night...

And for transformers, it's really early days for dfdx, but it's a library that aims to sit basically at the Pytorch level of abstraction, that the difference is it's not just coded in Rust, but it follows the Rust-y/functional-y philosophy of "if it compiles it runs".

Wow that is super interesting. I actually tried to use GATs at first to be generic over shapes, but I couldn't do it, I'm sure it would be possible in the future though. There is this library dfdx that does something similar to what you mentioned, but it feels a little clumsy to me.

Awesome, I added an issue here https://github.com/coreylowman/dfdx/issues/597. We can discuss more there! The first step will just be adding the device and implementing tensor creation methods for it.

The next release of dfdx includes a CUDA device and implements many ops. The same dev created a new crate, cudarc, for a wrapper around CUDA toolkit.

A question I have is: what are the philosophical/design differences with dfdx? As someone who's played around with dfdx and only skimmed the README of burn, it seems like dfdx leans into Rust's type system/type inference for compile time checking of as much as is possible to check at compile time. I wonder if you've gotten a chance to look at dfdx and would like to outline what you think the differences are. Thanks!