-
> It seems like support is spotty or it’s DIY
I can somewhat attest to this! I have a pretty extensive prototype of using Rust on ESP32 in production. I wrote a reference implementation for BRSKI, a secure remote key bootstrapping protocol which builds upon attestation keys and public key infrastructure.
I'm largely using `esp-idf-svc` for most things, which is a Rust-native wrapper around ESP-IDF code. For anything closer to the hardware, I'm using `esp-idf-sys` which is just a thin wrapper around the the `ESP-IDF` SDK.
You can see the project here: https://github.com/hm-seclab/open-brski
Hope this helps! I'm by no means an expert but I sometimes help contribute to the Rust ESP32 ecosystem, so ask away if you want :)
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
Rust compiles to native machine code. C# compiles to bytecode which runs in a runtime environment. That adds a huge amount of overhead, and means you don't have direct access to the hardware registers. The .net IoT framework is targeting computers running operating systems.
When you compile rust for an embedded target it's running "bare metal" - there's no operating system, the microcontroller literally just starts running the instructions your compiler put at memory address 0. If you want anything an operating system offers - task scheduling, memory allocation, file system access, network access etc - you have to compile it into the binary that's loaded into the microcontroller.
Only languages which compile directly to machine code are really suitable for that - C, C++, Rust (plus a long list of less common ones - this list of languages which can compile using LLVM is a good place to start https://github.com/learn-llvm/awesome-llvm?tab=readme-ov-fil...)
-
This was recently discussed: https://news.ycombinator.com/item?id=41801124
While it is true that Rust is a strictly superior option for highly concurrent systems code, it still leaves areas where you can make a mistake regarding lock management and other advanced forms of synchronization.
In addition to that, .NET as platform is fairly tolerant to misuse and calling the code that is not thread-safe from multiple threads concurrently usually leads to logic bugs or "stop modifying this collection concurrently, please" exceptions but not to catastrophic memory safety issues like it happens in C/C++.
You can read more on its low-level memory model here: https://github.com/dotnet/runtime/blob/main/docs/design/spec...
> The same is true for async, which in C# is also a problem.
Now, this one is strictly not true. Async primitives are thread-safe. In Rust, you must synchronize because at the very least you must deterministically deallocate memory used by shared state between the tasks. In C#, this complexity is handled for you by a GC (ironically, you get negative sentiment towards async from people having experienced Python's async or Rust's async complexity, assuming the same applies to C#). In some scenarios, it is also a throughput optimization since it reduces memory contention and cacheline sharing between the cores, lending itself into better performance on many-core systems - the memory is modified/reclaimed when it's no longer in use, while the actively shared data is placed elsewhere.
-
Rust solved this by autogenning code from mfgr published device xml descriptors. Eg https://embassy.dev/
Better than any C(++) embedded hal I've used
-
You can :) It just requires going out of your way a bit. It effectively works as C with better type system and generics, that can be either JIT or AOT compiled (statically linked too). For example https://github.com/bflattened/bflat has a target flavour that does not support GC at all.
-
For example, see a couple pages of comments by girvo [1].
Also there's a video on writing keyboard driver in Nim [2].
[1] - https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] - https://youtu.be/dcHEhO4J29U
-
nf-Community-Targets
:construction_worker_man: Repository with target boards provided by nanoFramework community members
Are you actually familiar with those projects, or are you just posting links?
Nano Framework is a framework to run C# apps on microcontrollers - but when you get to the hardware interfacing, it's done in C++. Look at https://github.com/nanoframework/nf-Community-Targets/tree/m... for an example. It appears to be using the ChibiOS RTOS at the low level.
Wilderness Labs have built a C# runtime on a microcontroller. But if you got access to their source code, I can guarantee that somewhere there's C++ or C code setting everything up, kicking off the virtual machine etc.
Nobody is claiming that you can't run bytecode-compiled scripting languages on embedded targets. Hell, you can even emulate other CPUs on embedded targets. But ultimately to set up a microcontroller and use its peripherals you need to be able to read and write registers on the memory bus, which means you need to be able to create assembly that the CPU understands.
There are projects to compile C# directly to machine code, bypassing the need for C++, C or Rust to set everything up. But those aren't at all mainstream. C# code expects a memory allocator and garbage collector. You'd have to explicitly run those somehow.
If you're already going to have to write some sort of board support package in a language that compiles directly to ARM machine code, then Rust is a great candidate. And if you're already writing your board support package in Rust, it might make sense to write your business logic in Rust too.
-
Stream
Stream - Scalable APIs for Chat, Feeds, Moderation, & Video. Stream helps developers build engaging apps that scale to millions with performant and flexible Chat, Feeds, Moderation, and Video APIs and SDKs powered by a global edge network and enterprise-grade infrastructure.
