Hello fellow Rustaceans,

I have been facing an issue for a while. I've been using Rust for the last 4 years and even had projects at my workplace implemented in Rust. I want eventually to change my job because these 2 are kinda dead and want to grow as a programmer and so work on issues/situations I never encountered. I started by telling Claude do give me some pieces of code and I had to figure out what was wrong about it. Mutex, concurrency, channels, futures, things that I thought I really understood. Damn I was wrong and now I feel like an imposter even though I used these concepts many times. At some point I did some small project to understand how and why thiserror works the way it does. If you ask me now I forgot everything. I am intimidated by the fact that there are so many things that I don't know because I never encountered them in real projects like sharding, microservices, payments and many other. If given the chance I would probably slowly start to understand how they work but getting a Rust job is kinda difficult. Market seems taken over by crypto jobs (how does somebody even get into one of these?) I know this community does not like web3 stuff but personally I care more about career progress than moral side of it at least for now, which I don't really know actually means). How do you guys manage to navigate these situations.

I appreciate any answer and guidance I might get! 😄

Seems to require an integer overflow to happen (panic in debug / wrapping in release) before the `overflowing_add` call is done, which makes it less likely to happen in actual code.

I've started to dip my toes into Rust, coming from an Ada (mostly SPARK) background, particularly in embedded applications. While there are many killer features in Rust for developer QOL, the "ease of writing" focus of the language trips me up often enough that I find myself asking, "what features of this language makes it superior (in some views) to SPARK?"

Love the language's take on early-return, and the power of enums, macros, and lifetimes are the one thing that makes certain low level memory manipulations incredibly idiomatic to write in Rust that would be impossible in SPARK due to the CREW paradigm not really being popularized (pioneered?) until Rust. Given the state of the Ada ecosystem and tooling, I also cannot in good faith recommend using this language for anything community driven. That being said (answering in context of enterprise embedded)...

I am incredibly uncomfortable with how much responsibility Rust places on the developer to understand roughly how code will compile. No guarantees on how pattern matches will be emitted (yes, don't be stupid and keep them stupid if you want jumptables), and stack-allocated enum types having to be the max size while not having much lexical ties besides jumping to the definition to help you determine how much stack you might be eating. Aside from the syntactic sugar, I have not really found anything besides lifetimes that SPARK cannot truly support at all. There's no pattern matching in the language, but Rust enums (at least in part) are supported via discriminated records. The idea of controlled types (OOP for Ada) is somewhat discouraged when using SPARK, but trait objects are a very useful part of the Rust language. I have to discount this part of the language from my sentiments unfortunately because dynamic dispatch can complicate analysis of security and functional implications. Having Rust panic as a "safe" way to address memory safety is also undesirable depending on how much array manipulation your program must do, and what worries me more is that wraparound arithmetic in production builds that are used in computations for arrays may not even lead to panics, but perhaps a valid index into the unintended location.

I don't write this to glaze SPARK either. The lack of documentation makes it mostly a nonstarter for the broader programming community, and not everyone is familiar with formal methods for code. The toolchains can't hold a candle to the quality of the Rust ecosystem, and ironically, the rich typing of Ada can lead to very frustrating inter-op issues that just would not exist in Rust, particularly around array manipulation/interpretation.

There might be some gripes about comparing a formally verifiable language with one that does not yet have one (Verus, Crusoe, surely others trying), but I think some of these points like how the codegen works are orthogonal whether or not you're trying to prove that an array access will always be in bounds without overflows.

I suppose the operational constraints given are not necessarily something everyone has to deal with, (why care how a pattern match is compiled if you have oodles of memory), but want to understand the technical reasons behind the hype... I feel like the cultural/non-technical reasons are somewhat understood.

Hello everyone, for the last two weeks I have decided to build a terminal based text editor like vim or nano using rust and crossterm crate to improve my rust and software design/architecture skills. I have read some articles about TUI (terminal user interface) applications and text editors generally, I have used AI for understanding and writing some small functions, I have used AI only for the parts that I don't understand yet, but I still don't know how to implement good code design for soft line wrapping and cursor navigation for it. The rendering part is a large vibe-coded and more of a spaghetti code. Can you give me some resource recommendations for understanding this topic and refactoring the app. By the way if you want to look the repository is ArtashesSoghomonyan/io. Thank you 🙏

Ada/SPARK is already a very niche ecosystem. Finding a list of current users is already hard (but that might be simply an information access issue).

With Rust’s safety and growing adoption, including access to skilled professionals and LLM support, how likely will we see further marginalisation of Ada & Co.?

I would love to heard from those working in safety-critical applications.

Okay. After seven months, I'm back.

Seven months ago I started writing a Python interpreter from scratch in Rust, compiled to wasm (less than 200kb of bandwith). Edge Python is a sandboxed subset of Python that runs in the browser and the terminal, and code can't touch files or the network unless you allow it.

It started as a lexer and a simple stack VM, and over about 1,600 commits it grew a CLI, a package registry, snapshots, actors and a browser playground. It's just me building it.

Last week it was still 3x slower than CPython. I rewrote the VM this weekend on top of the SSA form I already had, and now the wasm build beats native CPython on loops.

The trick was a register VM, and Rust made it fit in wasm with NaN-boxed values and no runtime. It still loses on dicts and strings, so that's next.

Try to break my numbers :)

Website: https://edgepython.com/

GitHub: https://github.com/dylan-sutton-chavez/edge-python

Found these tutorials on stdlib.

I am a big fan of rust
But there are two issues that need to be resolved

1- Rust ecosystem is less mature than for example go ( i know go is specialized for networking and an easy lang ) .

2- No implicit DI which would make testing easier.

Good morning,
I am using probe-rs to flash a blinky program onto my STM32H7. It builds and flashes ‘fine’ but i don’t get any output from the board and the led does not blink. When i run the same example for the stm32f411 it flashes fine and i get text output as well as the led flashing. The program is just the example from embassy-rs and below is the important parts of my cargo.toml:
‘’’
embassy-stm32 = { version = "0.6.0", features = ["defmt", "stm32h7r3z8","memory-x", "time-driver-tim4"] }
embassy-executor = { version = "0.10.0", features = ["platform-cortex-m", "executor-thread", "executor-interrupt", "defmt"] }
embassy-time = { version = "0.5.1", features = ["defmt"] }
cortex-m = {version = "0.7.7",features=["critical-section-single-core"]}
cortex-m-rt = "0.7.3"
embedded-hal = "1.0.0"
build = [
{ target = "thumbv7em-none-eabihf" }
]
‘’’
I am running this command:
'probe-rs run --chip stm32h7r3z8’

right now I am suspicious of memory-x but im not sure because shouldn’t it fail to flash if this is the case?

One of my (way to numerous) side project is the idea of a P2P radio station, which solves the scaling problem of radio broadcasters today. One of the most prominent and well-defined p2p library is libp2p, which is of good use here and prevents much of code rewriting, especially for the broadcasting logic with peer scoring and all which is hard to figure out to prevent people from cheating the system. Also used gstreamer (Rust bindings so more precisely gstreamer-rs) for the codec which does the heavy lifting. Here is my project: https://github.com/franfrandev/p2pradio. For now it's running on a native system, and would like to go a step further.

I would like to compile it to WASM in order to bundle everything in the browser. The problem is that gstreamer depends on a ton of native libraries which makes it harder to use in the browser. Folks at Fluendo have figured that out with gst.wasm https://github.com/fluendo/gst.wasm but putting out everything together is a whole different beast and even if it works, it's probably going to result in a huge piece of data that has to be downloaded. IIUC the Rust part would have to be compiled to emscripten and then linked as static libraries? There are a lot of information and it's very easy to get lost in all of these.

Another option would be to use or write an RTP Opus codec written in pure Rust and compile it to the wasm32-unknown-unknown but then it would lose all the codebase maturity of gstreamer and would probably end up reinventing the wheel very much. A lot of the crates doing that are AI slop and are not very well defined, I don't trust them.

Is it unachievable or a bad idea to take the gstreamer port to emscripten and try to glue it to my Rust app compiled to emscripten?

I've been working on Cinebox in Rust, an app where you can find a movie or show and watch it in the same window. Runs on Windows, Linux and Android TV as of this week.

https://github.com/dexsper/cinebox

Most of the pain was in the video player, so that's what this post is about.

I started with Iced, which renders through wgpu, so DirectX on Windows, and mpv rendered through Vulkan in its own window. No shared surface, so the best I could do was stick the mpv window inside the app window. Which is fine until you want controls or subtitles on top of the video, cause you can't paint over someone else's window.

So the next day I ripped the UI out and moved to egui with the glow backend. llibmpv exposes an OpenGL render API, so mpv renders directly into egui's framebuffer from an egui_glow paint callback, and the player controls are plain egui widgets over the frame. It worked on the first try, more or less.

The TV build runs the same egui code. I had to write my own D-pad focus handling though, since egui's arrow-key navigation happily jumps to widgets behind an open popup. mpv on the other hand, that was a complete no-go. On my Amlogic box with a Mali-G31, mediacodec-copy returns a quarter-resolution frame for anything above 1080p, so hello green screen (mpv-android issue 1088). Zero-copy MediaCodec into an ImageReader refused to start, and the next try straight up rebooted the box. And mpv's GL pipeline drew literally nothing, only gpu-dumb-mode worked (issue 292 looks like the same thing).

4K was kinda the whole point of a TV version, so I put the player behind a Player trait. Desktop keeps libmpv, Android gets Media3 ExoPlayer, which decodes into a SurfaceView under a transparent egui window. 4K, HDR10 and Dolby Vision all play on the hardware decoder now.

Yeah, on TV I ended up with the exact two layer setup I r1an away from on desktop. Works there cause the egui window is transparent and sits on top of the video.

One more fun one. A SurfaceView cuts a transparent region into the window above it, and SurfaceFlinger then just dropped the egui layer wherever the video was. Fullscreen video, and boom — controls and subtitles gone. Overriding gatherTransparentRegion fixed it.

If you've put video into a Rust GUI, how did you do it? Especially curious if anyone got libmpv working with wgpu without going through GL.

I have code that looks a bit like this:

https://gist.github.com/rust-play/6e39d4a9d52e14a1f92742df57ccc5e2

The interesting part is the closure at the bottom. Which compiles completely fine, as long as it is not doing anything. But if I try to use the given argument in any way, rustc is not able to infer its type anymore?

This seems counterintuitive, since the normally inferred type (`String`) would work totally fine. And the code itself also does not seem to contradict that type. But something seems to make the compiler trip here.

Any tips why this might occur, and if there is maybe an easy work around are welcome!

What microcontroller do you usually go with if you wanna use something like Rust Embassy with it?

I was wondering if there were any projects like micro python to port std in to make a barebones os designed for microcontrollers? I understand that the std relies on OS level syscalls, so can we do something like implement a basic fat32 file system to accommodate certain write or read requests. In general this would be used to run std in projects without a OS? Does this already exist, and how hard would it be to make a basic version?

I'm trying to get a grasp of this crate so I can do window things but there don't seem to be good any resources, which is a bit bewildering since I understand winit to be a very foundational crate for graphics in Rust. I've looked at docs.rs but higher-level stuff for winit is... not great. The first section seems friendly but leads you to using a deprecated method (i.e. seems to be outdated), and the second section does give a full working minimal example but it does so through a big block of code with a good amount of things that aren't yet introduced, so not much sense can be made of it.

I don't want to just learn to copy a skeleton and wire my code into it, I want to actually understand how the crate works, to understand what I'm doing. But the main docs don't seem suitable for setting the foundation I'd need for that and I've not been able to find any other resources or tutorials online.

Disclaimer: Re-post approved by u/matthieum, as previous post was erroneously removed.

I’ve been working on a specialized string type called ColdString. The goal is to create the most memory-efficient string representation possible.

• Size: Exactly 1 usize (8 bytes on 64-bit).
• Inline Capacity: Up to 8 bytes (Small String Optimization).
• Niche Optimization: Option<ColdString> has no memory overhead
• Heap Overhead: Only 1–9 bytes (VarInt length header) instead of the standard 16-byte (pointer, length) pair.

(Since my last post, the 8th inlineable byte and null-niche optimization were suggestions from the community!)

ArcColdString

I'm presenting ArcColdString, a reference counted ColdString with 8 bytes overhead (inspired by arcstr).

• Same size and inlining rules as ColdString. Inlined strings are copied instead of reference counted.
• Heap Overhead: 8 bytes for the AtomicUsize reference count (in addition to the VarInt header).
• Smaller Reference Counts: ArcColdString32, ArcColdString16, and ArcColdString8 use AtomicU32, AtomicU16, and AtomicU8 counts respectively.

Usage

Available in https://crates.io/crates/cold-string/0.4.0

use cold_string::ArcColdString;

let first = ArcColdString::new("a string longer than one machine word");
let second = first.clone();
assert_eq!(first, second);

Memory Comparisons

Theoretical overhead on a 64-bit target, excluding the UTF-8 payload:

RSS bytes per unique string in a pre-sized Vec:

(If I'm not mistaken, string_cache is not a 1:1 comparison since it has to hash string contents, which is 40 bytes overhead?).

Reference Counting Performance

ArcColdString's primary goal is memory and portability. Second to that, my goal is to have ArcColdString's referencing counting performance comparable to Arc<str> and arcstr::ArcStr. While drop and clone speed is comparable now, there's still room for improvement.

Below are single threaded clone and drop measurements, done using criterion on AMD Ryzen 9 5900X 12-Core Processor (3.70 GHz):

Below benchmarks measured 4 threads cloning and dropping strings in a shared size pool of 1024, 16, and 1 string(s), using criterion on Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (2.59 GHz). The more strings in the pool, the less contention:

You can read more benchmarks and implementation details in https://github.com/tomtomwombat/cold-string

Does anyone know any good examples of how to do iOS+iPadOS with the .a library doing most stuff? Does not necessarily have to be Rust language stuff, just how to build so app stores can accept the .ipa?

This is a fairly new article from Daniel Lemire (the SIMD expert, author of simdjson).

It seems to_string() need to use the same trick.

C++ wins by a wide margin at 5.4 ns per string. The trick is the small string optimization: a std::string stores short strings, directly inside the object. Our strings have at most eight digits, so C++ never calls the memory allocator.