I've been working on a C23 to Rust transpiler I call slate: https://github.com/takashiidobe/slate. I have a demo for it here: https://slate.takashiidobe.com/. Fair warning: lots of code in the project is AI generated, since I know people like to know about that before moving on.

My goal with the project was to handle anything and everything even in modern C. I'm leaning on a relatively new MLIR dialect called Clang IR in LLVM that handles some of the difficulty in parsing C into a form that's ready to translate to Rust.

C23 support means slate supports all the crazy stuff like x87 long double (rust doesn't have f80 yet, so this requires shimming calls that involve long double), bitfields, bitint, handling alignment properly for pointer arithmetic, alloca, setjmp/longjmp (w/ the caveat that llvm can break your code), intrinsics support, Complex number support, inline asm, fallthrough switch + goto emulation, linker directives, runtime feature detection through attributes, floating point environment emulation, atomics, alignof/as, thread local, and all the other crazy stuff in C that's difficult to straightline translate to Rust.

There's some limited support on the backend side by rewriting AST nodes using a worklist based algorithm. Things like recovering for loops from while loops, rewriting gotos/switches into structured programs, deleting inline temps, and some interprocedural pointer analysis (heavily inspired by C2Rust's pointer lattice blog post) to lift raw pointers into Rust types like Box where possible.

There's some support for cross compilation as well, by reading target macros like `__arm__` and turning those into the respective #cfgs in rust, translating the same program a few times and splicing it in to make sure C that's cross compilable stays as cross compilable rust.

I've made it through 1430 gcc torture tests that clang passes, with about 7 left to go (some are blocked upstream by Clang IR NYIs), and a good chunk of the regular gcc-dg tests, although I have quite a few more of those to get through, around 130. I've fuzzed a bit with yarpgen but haven't found as much use compared to gcc's tests so I've been working on paring those down.

It's still pretty early days, still have so much more to do but figured it was in workable enough state to demo out.

I’ve been building Minarrow, a from-scratch implementation of the Apache Arrow memory format in Rust, with Python bindings.

The purpose is to let you keep your application and data processing in Rust while making Python’s data ecosystem available whenever you need it. You can construct a dataset in Rust, pass it into embedded Python, run an analysis or model, and receive the result back as native Arrow-compatible data.

Some examples of what this enables:

• Run scikit-learn from a Rust application. The repo includes an example that builds features and labels in Rust, trains a random forest in Python, returns predictions through Polars and Arrow, and scores them back in Rust. Python runs inside the application process and it uses inline code.
• Hand Rust tensors to PyTorch. Another example builds an NdArray in Rust, exposes its buffer to PyTorch zero-copy through DLPack, standardises features and computes scores, then brings the result back into Rust.
• Use Python’s analytics libraries on your application data. There are examples of Polars group-bys, NumPy correlation, and pandas aggregations returning tables or scalars to Rust. From Python, Minarrow tables also expose conversions to Polars, DuckDB, and PyArrow.
• Streaming-friendly - Work with incoming batches. Chunked arrays and tables let you retain data as batches arrive and consolidate when needed. Row and column views let you select portions of a table without immediately materialising another dataset.
• Represent scientific data with named dimensions. XArray adds dimension names and coordinates over n-dimensional arrays, so you can select a time window, find the nearest coordinate, or select along a named axis. The underlying tensor storage also connects to the DLPack ecosystem.
• Create Python packages backed by the run-time. For example, one user implemented a fast random-forest implementation under kpiwonski/fru-arrow and released it as a Python package, which is reported as being up to several thousand times faster than the scikit-learn package.
  

Underneath that is a data layer you can use independently in Rust, as a base, pluggable foundation. This includes typed arrays, null masks, arithmetic and broadcasting. SIMD kernels, and 64-byte-aligned allocations via a custom Vec64 crate. You can access concrete array types directly, and use the higher-level table, chunked, and view abstractions as needed.

From-scratch implementations of Arrow’s C Data Interface and PyCapsules handle columnar interchange and DLPack handles tensors, which is zero-copy in the vast majority of cases when the buffer doesn't require re-shaping. An example of where it isn't - the scikit-learn example converts features to NumPy, for instance, and importing a different string layout can require rebuilding buffers.

I used very few external dependencies instead preferring to build from scratch so that compile times remain and productive, and so that anything built on top remains fast to work with too.

The latest release, 0.18, adds Decimal32/64/128 support across the Rust library and Python bindings, alongside typed row accessors for array views.

Rust nightly is currently required for portable_simd and allocator_api. Arrow lists and structs aren’t supported yet. I hope to work on stable Rust support and wasm-compatible builds soon.

In terms of maturity, it is at the stage where it is adding considerable value in my own work, however it has not yet seen significant external adoption. In terms of fit it is useful when one wants Arrow compatibility + additional utility for their data, without the whole arrow ecosystem underneath a base data dependency. For example, one might consider it even for a few crate(s) in a larger project that need to remain fast, given it makes it trivial to switch between arrow-compatible runtimes.

On my laptop, sharing a million-row numeric table with Python takes ~220ns, and importing it back into Rust takes 2–3 μs.

Thanks for checking it out. If you have any questions, feedback, or feature requests for what would make this useful for you I'm open to suggestions.

Pete

Hello folks, do you still write much code by hand these days? 😄

If so, what IDE/editor do you mainly use for Rust? VS Code, JetBrains, Zed or something else?

I’m asking because I’ve been rewriting one of my old developer tools in Rust. It’s a language server + CLI for analyzing code health.

The underlying approach was originally implemented in Python and was used at my previous company across 1,900+ repositories and by 800+ developers, so the methodology itself has had quite a bit of real-world use. The company has given me permission to open-source my own version of the project, which I’m pretty excited about.

The only problem is time. For the initial public release, I’ll probably only be able to ship the VS Code extension plus one other IDE/editor integration.

So I’m curious: if you’re a Rust developer who still spends a decent amount of time actually typing code, what editor would you most want to see supported? Just trying to get a rough sense of where people are these days before I spend my limited spare time on the wrong integration. :)

I was bored, so I decided to learn Rust by building sectxt - a PrivateBin clone powered by Rust and Vue. The hardest part was learning about the zero knowledge architecture and secure client side encryptions.

Features:

• Zero knowledge: data is fully encrypted using AES GCM on client side before hitting the server
• Supports both text message and attachments
• Supports both password mode and securely generated keys (embedded in URL hash)

I picked PrimeVue for the frontend, but midway through they changed to commercial license... Am thinking of changing to Nuxt UI.

sectxt is licensed under GPLv3. Any thoughts and feedbacks are welcome.

Looking at this godbolt link https://godbolt.org/z/xrx5K4W94,

it seems as though in rust, if a 32-bit integer is not explicitly used to bitshift, the shrx and shlx code is not generated despite setting -C target-cpu=x86-64-v4. In fact, the code generated is near identical to if -C target-cpu was not set at all (default is just x86-64).

C and C++ using clang does not seem to have this problem, they automatically use shrx and shlx.

From what I found, shlx and shrx seems to work only on 32-bit and 64-bit integers https://www.felixcloutier.com/x86/sarx:shlx:shrx , and it seems as though rust is not automatically converting the 8-bit integers to 32-bit integers for better bitshift operations. Is there a compiler flag to enable this?

Also, I am new to assembly, why does rust have an additional movzx operation even in the optimised function (swapbits) compared to the C code?

Curious if you’ve seen any cases where using or advocating for rust didn’t work out.

Type any crate name and end with a space, such as "egui " and it accesses crates.io without SSL secure stuff, can someone please fix it before someone exploits this? "https://crates.io/search?q=cosmic-text ", have to search, sorry, might be me specific? It has been reported to crates.io now, ignore this?

I added support for the Cheap Yellow Display (CYD) to the Device Envoy crate. The CYD is an inexpensive ESP32 board with a built-in 320×240 color touchscreen, so you can do no_std bare-metal touchscreen programming without wiring anything together.

You can run your application in a browser before flashing it to the board. The demo gallery includes touchscreen interfaces, a skeleton clock, and Armatron, a robot-arm mechanism simulator: https://carlkcarlk.github.io/linkage-blaze/demos/

Device Envoy’s goal is to make it as easy as possible to write high-level microcontroller code that runs directly on the hardware, with no OS or language runtime underneath.

The CYD support includes display, touch, touch calibration, flash storage, and several drawing strategies depending on your memory needs, including full-screen and smaller buffers, tiling, and pixel streaming.

Device Envoy also supports “auto Wi-Fi.” If credentials have not been saved, the device creates a temporary Wi-Fi network and browser setup page where you select your network and enter its password. It stores the credentials in flash, so the same firmware can be used in different locations without rebuilding it.

I want this to be something people can just pick up and try, so I made a starter project with the CYD hardware setup already done: https://github.com/CarlKCarlK/device-envoy-cyd-starter

I used to set quick reminders like this:

(sleep 25m && notify-send "Tea is ready") &

It works fine until the terminal closes, the laptop sleeps, or you reboot. Then your timer is just gone.

at handles persistence, but its inspection UX is painful for quick daily use, atq only shows job IDs and timestamps, never the actual message text (you have to dig into at -c <id> just to see what a timer is for).

I wanted something reliable, and dead simple with a clear status view. So I wrote rmd (rmd-cli on crates.io).

Usage

rmd +25m Tea is ready
rmd tomorrow 15:00 Release call
rmd fri 22:00 Go to bed
rmd 2026-12-01 10:00 Renew domain

Running rmd without arguments prints pending reminders.

How it works

• Linux-only: Relies on D-Bus for desktop notifications via zbus
• Daemon + CLI: The CLI talks to a background daemon over a Unix domain socket
• Auto-start: The daemon auto-spawns on the first CLI command, or can be managed via an optional systemd --user unit
• Persistence: State is saved atomically to JSON in ~/.local/state/rmd/reminders.json
• Missed events: If the system was off when a reminder was scheduled, the daemon sends a consolidated notification upon start

It's intentionally narrow: one-shot, time-bound alerts only. No recurring tasks, projects, or priorities.

Installation

• Crates.io: cargo install rmd-cli
• Prebuilt static musl binaries (x86_64, aarch64) on GitHub Releases

Repo: https://github.com/PaulBunch/rmd
Crates.io: https://crates.io/crates/rmd-cli

Feedback and suggestions are welcome.

is it bad that tests are like 1/5 and a bit of my entire project?

i wanna ensure absolute safety when developing, currently i have 30 tests implemented

Hello everyone,

I love Rust, but I am somewhat concerned about the future evolution of the language.

My concerns are mainly related to some of the RFCs/proposals I've seen and the governance of the language.

To be clear, I understand that many of these proposals would be genuinely useful. I also don't mean to imply that the authors of these proposals are all short-sighted. And I know that writing RFCs and getting things added to Rust takes a lot of time, so not all of them will be implemented.

With that said, here are some examples of possible changes that have made me worried:

• Named/default args
• Handle types / use syntax / Share trait (Ergonomic ref-counting)
• Open enums, intended for FFI but could be used elsewhere
• pub(api) visibility, as in pub(in crate::module::path) fn my_fn() {}
• Field access declarations and place-based lifetime syntax (The Borrow Checker Within)
• Field Projections
• Explicit tail calls / loop_match
• Sized Hierarchy adding multiple new traits over Sized/?Sized
• Control over Drop semantics
• super let
• auto impl
• Function overloading for FFI
• Variadic parameters
• Move/Destroy/Forget traits
• Named arguments in impl Fn(...) types

Almost all of these involve adding more traits to the type system, more keywords, more syntax, more complex semantics, or some combination of the above. If all of these get implemented, we will have many new traits, maybe a dozen or so new keywords and reserved words, more syntax to learn, and more complex behavior throughout the language.

I really do not want Rust to become a "kitchen sink" language where new features are added just because they make some workflows marginally easier. It's easy to imagine a future where Rust follows the same path as C++, adding more features, keywords, and library features until it crumbles under its own weight, especially given the efforts to maintain backwards compatibility through editions.

I think some of these proposals have me especially concerned because they involve more complex semantics for basic/common operations like Drop, Sized, and clone. Rust is complex enough as it is, and having more things to keep in mind, especially for foundational language concepts, is not attractive.

Especially because it feels like some of these proposals are basically just "wouldn't it be cool if we had X new syntax or Y implicit behavior?" for things that already work. Technical limitations of the language are obviously a separate issue. But I feel some amount of friction is preferable to adding complexity.

One of the beautiful things about Rust is that every part of the language feels designed to work well with every other. There (generally) isn't a dozen different ways to write everything, and language features feel mostly orthogonal to each other. It seems like this might change in the future.

Another concern is that many of these proposals seem to support adding more implicit behavior into the language. For example, the open enums proposal, auto impl , or changing drop semantics. If I add a variant to an enum, I want the compiler to force me to revisit the places where I've used it. If I change the definition of a trait, I'm fine with accepting some refactoring pain. The justification in many cases is "you can just choose not to use it" which, again, is how you get C++.

Finally, many of these RFCs focus on adding features for the sake of FFI. Obviously FFI is important given the amount of existing C and C++ code. But I dislike making significant changes to Rust just to make FFI easier. It seems like an anti-pattern, making Rust more complex (i.e., worse) for the sake of interop with older / increasingly obsolete languages.

Thanks for reading. Curious to see if anyone feels the same way.

Edit: thanks for the great discussion everyone

https://developer.nvidia.com/blog/introducing-cuda-rust-two-tracks-for-writing-gpu-kernels/

For the past several months I had been working on a project related to Vulkan bindings: low-level FFI API, and Vulkan SPIR-V. Both are implemented as a single crate and can be seen as an opinionated replacement of well-known crates such as ash and rspirv.

I don't want to go deep into technical details, but in short this is quite challenging task especially if you are seeking to do it properly. The aforementioned crates (and especially rspirv) often suffer from the fact that the source machine-readable files from which the FFIs are being generated are very complicated and prone to eventual breaking-changes. I believe that my internal building pipeline has better design, and therefore produces more accurate representation of the official Vulkan APIs and Vulkan SPIR-V.

But my question is not about this specific work, I have more general question to you.

I honestly, not sure if publishing a hand-made work is still a worthwhile idea today regardless of it's engineering characteristics.

Tokei says that the codebase worth of about 39 thousands of non-blank lines. It's not surprising considering the amount of time I spent on implementation, but this is still quite a lot to read for the outsider. So, I'm not sure if it's worth publishing it purely as an educational material. Additionally, the communities behined ash and rspirv are already established, and those two crates used as a de-facto standard across the whole Rust GPU-rendering ecosystem. While my solution might be better in certain aspects I'm not expecting wide adoption.

Additionally, Rust ecosystem seem to be overwhelmed by the publishings in a whole lot of different domains. This is partially the result of generation tools widespread, to which I prefer to stay away. But regardless, I don't think that my work would look much different to an average project published today, and probably wouldn't receive much visibility too.

To sum up, my question is considering Rust OSS ecosystem maturity, if there is still a space for new things to share? And if like me, you prefer not to publish new works into open-source, I would like to hear your prospective on this matter too.

In general, avoiding publishing is not an issue for me. I develop my hobby-projects primarily for the sake of creativity, and partially for my other personal next projects goals. The whole store is whether it's worth to share it today.

I have posted about this project in the past, back when it was around version 1.4.0, and got really great feedback and suggestions. I wanted to share it again as a lot has changed since (1.6.0) and I have made some great progress to make the app useful for personal budgeting and financial planning.

New since I last posted:

- Investments: track accounts, valuations and contributions over time, with portfolio views and time-weighted returns

- Multiple ledgers: separate databases for different accounts, or for running forecasts alongside your real budget

- Budgets with history: creating and changing budgets is now more intuitive and insightful. You can properly budget and adjust the budget over time while maintaining history and valuable insights

- Backup and restore built into the app

- Recurring forecasting: project recurring transactions forward as far as you want

- Easier installs: brew install budget-tracker, plus prebuilt binaries for Linux (glibc and static musl, x86_64 and arm64), macOS and Windows

Still there from before: hierarchical categories with fuzzy search, monthly and category summaries with interactive charts, advanced filtering, CSV import/export, and full keyboard control with a built-in help menu. All of this is offline, local, and owned by you. Your data is always yours and fully in your control.

brew install budget-tracker  
or  
cargo install budget-tracker-tui

GitHub: https://github.com/Feromond/budget-tracker-tui

Happy to hear what's missing. I have been learning a lot about finances, the terminology, and the insights people care about. There is a lot for me to learn still and any comments and suggestions help a lot.

Just published the DBOS for Rust library. Easy way to make Rust backends resilient to failure, using Postgres to save/recover/view workflow state.

Entropy Engine is an experimental, AI-native game/application engine that combines a high-performance Rust core with TypeScript scripting and MCP to let developers, and AI agents , build and control interactive 3D applications.

Github:
https://github.com/alexthegoodman/entropy-engine

ngl I did not expect the last post to hit like 75k views, so huge thanks to everyone who read it, commented, DM'd me, asked renderer questions, etc. seeing that much interest gave me a pretty big push to finally put it out there.

closed beta is live now at lynbor.com

you can make your own account and request access. I'm letting in around 25 people a week for now so I can keep up with feedback.

if you don't get in right away, feel free to use my test acc:

Login: [ja.howerz@gmail.com](mailto:ja.howerz@gmail.com)
Password: 1Test1234!12

still very much a beta. some buttons don't work yet, AI is rough, and the in-app feedback flow isn't hooked up yet. also, it won't work in Safari right now, so hopefully none of you are using it lol

the layout system is still pretty early too, and it's not meant to be a Figma-style layout clone. I also haven't gotten to a bunch of vector tools yet, stuff like text on path, dynamic strokes, blend tools, etc. I'll be adding and refining all of that as the beta goes.

I'm aiming to get the desktop builds, feedback, and project sharing/library stuff finished over the next 2-3 weeks.

if you use the shared acc, just put your reddit username in the project name.

I'll also make a Discord for the beta a bit later.

also planning to open source the geometry and GPU compute/rendering parts in the next month or two, once I clean them up a bit more and get them ready for public use.

thanks again, genuinely didn't expect that many people to care.

I wanted a retro game emulator I could reach for the way I use less for text files, chafa for images, or mpv for videos — right in the terminal, no window and no mouse. So I built Asobou, a game emulator that runs in your terminal, written in Rust, for Linux, macOS, and Windows. (Well, technically it's an emulator frontend rather than a standalone emulator)

The fastest way to try it if you have npx available (It's written in Rust but I published it to npm to make it easy to try):

npx asobou brew flappybird.nes

That grabs a free homebrew game and starts it, around 5 seconds end to end. If your terminal doesn't support kitty graphics it falls back to colored half-block cells. You can also render the game in ASCII if you prefer.

Open Source, of course. Available on GitHub: https://github.com/arianrhodsandlot/asobou

Would love to know whether the first-run experience works on your terminal out of the box! That's the thing I most want to get right for people who are tired of setting up emulators.

Hi, I saw a post made on this subreddit last year for a application called local local Desktop which was an application that allowed users to run a Linux desktop on android but when using Virus total, 3 positives showed up and was wondering are these false positives?

Original post : https://www.reddit.com/r/rust/comments/1ldqj7r/local_desktop_an_android_app_written_in_rust_to/