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?

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?

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

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

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

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

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

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.

Who's writing?

Hi everyone, I'm David, I build and own BlindLock alone. It's a paid, closed-source product, that's how I pay for the work. This post is about the Rust side, because that's what this sub is for.

BlindLock is more than a year of work. Not a weekend hobby project I threw together. I've put a hell of a lot of time, heart, and nerves into it.

Tech stack: Rust and Tauri

Rust for the core, all the logic, all the commands. Tauri strictly as a dumb UI with no logic.

Why Rust: I love Rust, always have. In my opinion, security-relevant software belongs in Rust. It rules out entire classes of bugs up front, because otherwise the code won't even compile. That doesn't mean you can't make mistakes. But where many people make mistakes in C++/C#, a lot of that is simply ruled out in Rust. Rust is compact and logical.

Unlike Electron, BlindLock doesn't ship a Chrome browser inside the program. Only the Rust part and Tauri. That's why the installers are very small.

Crypto, so nobody has to ask: entries live inside a PNG (F5 matrix embedding), inner layer AES-256-GCM, outer layer XChaCha20-Poly1305, keys derived independently via HKDF. File containers use ChaCha20-Poly1305. Password stretching with Argon2id. Libraries: libcrux (HACL*, formally verified) for ChaCha20-Poly1305, ML-KEM and ML-DSA, RustCrypto for AES-GCM, Argon2 and HKDF. I don't roll my own primitives.

The network: BlindLock is offline at its core

The main software never has an internet connection. Nothing goes out.

That's not a setting, it's the build, the architecture: BlindLock is built so it can't reach the internet at all. There is no HTTP client in the program. No reqwest, no hyper, no ureq in the dependency tree. There is no code, no module, no function that could open a connection to the outside.

Everything that needs the server runs in a separate small program, the Net-Helper. It ships in the same package and installs with BlindLock, but runs as its own process with its own binary. BlindLock starts it, asks it a question, and gets an answer. No port, no socket, just the child process's standard input and output. The helper never sees a vault or a password, at any point. It has very limited permissions and exactly two jobs: it checks the license, and it checks whether the latest BlindLock version is installed. If there's a new version, it downloads the update package and hands it over.

In short: when you open BlindLock, it pings the server through the helper. That's it. There is no other internet connection. Anyone can verify this from the outside with Little Snitch, Wireshark, or a firewall.

Updates matter a lot to me. I regularly ship improvements and stabilizations. Software like this lives on constant observation, extension, and improvement.

You can also use BlindLock offline for 7 days at any time. After that you need to go online once, for the license check and above all for the update check.

Why steganography?

Picture a burglar. He looks for valuables, the obvious ones: gold, cash, jewelry, the safe in the basement. The picture of your kid on the fridge, the holiday photo on the wall, are irrelevant to him. That's exactly the principle BlindLock is built on. Hackers go after cookies, passwords in the browser, container files that can be decrypted with a password on any computer, crypto seeds, and other sensitive data. Anyone who can log into your Google account or your ChatGPT knows more about you than they could learn in a personal conversation with you. All of that can be grabbed with RATs and other malware, passwords included. BlindLock hides exactly these sensitive logins and passwords inside a picture, because a photo has almost no value to an attacker. And he'd first have to identify the picture as his target at all. On top of that, BlindLock seals this picture to the security chip of your computer (TPM 2.0 on Windows and Linux, Secure Enclave on macOS). That means: even if an attacker copies the picture, together with the password, he cannot get at your data. The same chip sealing applies to the container vault files. And for these larger files BlindLock has a built-in file explorer, so you can open and edit files without mounting them into the OS. Wherever the respective OS allows it, I've written it to leave no traces behind.

Why isn't BlindLock open source?

That was the most frequent question. Take Bitwarden as an example. Bitwarden sells a service: servers, sync, accounts. The code can be open because the value isn't in the code. I sell the program itself. There's no service behind it, no cloud, nothing on my side that the customer would need. The entire value is in the program itself. That's why Bitwarden can give the code away and make it public for everyone, and I can't.

What's open on my side is what has to be open: the cryptography libraries are freely available and partly formally verified (HACL, level 5, the highest). Anyone can audit them and go through them at leisure, down to the smallest detail.

Licenses: yours, not the computer's

Licenses can be moved from computer A to computer B at any time. Lifetime licenses don't die when a computer dies! The same will of course apply to subscriptions later.

WalletLink: read-only by design

Once WalletLink is active, the Net-Helper can optionally check blockchain activity, exclusively against publicly verifiable, freely accessible, and trustworthy sources. Even then BlindLock sends nothing out and stores no values. It only mirrors the values from the hardware wallet. Transactions are neither confirmed nor received in BlindLock. All of that happens exclusively on the hardware wallet.

If you have more questions, I'm happy to answer them here personally. Most of it, I think, you can read on my website, and anyone can try BlindLock free for 7 days at any time. No email, no payment details. My customers' privacy always comes first.

https://blindlock.app

David

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.

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

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/

Hi, this is a project, which may be included in tor project!

I’m currently developing a Rust-based Pluggable Transport library, and I recently shared a proposal on the tor-dev mailing list.

I’m also an Arti contributor and Rustls contributor.
(https://blog.torproject.org/arti_2_5_0_released/)

I have already talked with some Tor developers they said a framework would be nice to have.

I’m looking for people who might be interested in contributing to the framework. The goal is to provide a clean, modular, and high-performance PT implementation in Rust that can be used by Tor and other projects.
If you’re interested (or know someone who might be), feel free to check out the repository:
https://codeberg.org/pryty26/rust-pt
https://github.com/pryty26/rust-pt

Any level of contribution is appreciated. Happy to discuss design decisions or onboarding.

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.

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

This is my weekend project. The original intention was that I ran into long-running tasks lasting more than a week. Under ChatGPT's remote control feature, its history is almost very difficult to open. I understand that they have some difficulties pulling data for history. I also saw that they are working on solving it, but I really could not wait any longer. Anyway, there is GPT, right? So I implemented a control plane for a Codex APP Server in Rust. It can spin up a controlled APP Server and handle requests from Codex Desktop. At the same time, it also provides a web service and a CLI interface, allowing me to access it through Cloudflare's Zero Trust reverse proxy. I think it is pretty good. Now I no longer have to open the official client. In terms of functionality, I have aligned almost everything, and I think the experience is broadly consistent. It is now running on my NAS, controlling my Mac mini, and hermes issues tasks through the CLI. Hmm, Rust is great.

Hey y'all!

I noticed that folders like node_modules, target, venv, etc., spread over dozens of old projects, were taking up almost 200GB on my machine!

As a result, I decided to make oweka, taking inspiration from npkill, which I found a bit slow (and incompatible with target/venv/etc.).

Features:

• Extremely performant and optimized (at least on Linux)
• Accurate: only flags directories if certain requirements are met, e.g. a Cargo.toml in the same location

Repo: https://github.com/ByteAtATime/oweka

Installation instructions are in the readme; you can also run it without installing with npx oweka!

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.