DemandMap - memory map anything on S3 and "Download" a 600mb polars DataFrame in 100ms. [Demo]
https://github.com/sonthonaxrk/demandmap
https://redd.it/1up7vjo
@r_rust
https://github.com/sonthonaxrk/demandmap
https://redd.it/1up7vjo
@r_rust
GitHub
GitHub - sonthonaxrk/demandmap: Memory map numpy arrays on S3
Memory map numpy arrays on S3. Contribute to sonthonaxrk/demandmap development by creating an account on GitHub.
Nevi v0.2.0 is out: a terminal editor in Rust built around Vim muscle memory
A few weeks ago, I shared Nevi here for the first time. It’s a terminal editor I’m building in Rust for people who want Vim/Neovim muscle memory, but with modern editor features like LSP, tree-sitter highlighting, fuzzy finding, themes, and project search built in by default.
I just released v0.2.0, which is the first version I feel more comfortable pointing people to.
What’s new since the first post:
\- Rendering is noticeably snappier. Nevi now repaints only the parts of the screen that changed in many common editing paths, with better handling for long lines and large files.
\- Go and Ruby language support.
\- More Vim/Neovim keybind parity, including
\- Labeled jump navigation with
\- Project-wide find and replace with a preview before applying changes.
\- nevi view, nevi diff, and nevi pick CLI modes.
\- Better
\- A Vim oracle test harness and render regression tests to catch regressions earlier.
\- macOS/Linux CI and Homebrew install/update docs.
Install on macOS with Homebrew:
`brew install anthonyamaro15/nevi/nevi`
Repo: https://github.com/anthonyamaro15/nevi
Old post for more context: https://www.reddit.com/r/rust/comments/1u7qwbm/im\_building\_nevi\_a\_terminal\_editor\_in\_rust\_for/
It’s still early, but it’s getting closer to the editor I wanted: Vim-like editing without spending a bunch of time maintaining editor config.
If you try it, I’d especially love feedback on which Vim/Neovim keybinds or editing behaviors your hands expect that still don’t work yet.
https://redd.it/1uph0l2
@r_rust
A few weeks ago, I shared Nevi here for the first time. It’s a terminal editor I’m building in Rust for people who want Vim/Neovim muscle memory, but with modern editor features like LSP, tree-sitter highlighting, fuzzy finding, themes, and project search built in by default.
I just released v0.2.0, which is the first version I feel more comfortable pointing people to.
What’s new since the first post:
\- Rendering is noticeably snappier. Nevi now repaints only the parts of the screen that changed in many common editing paths, with better handling for long lines and large files.
\- Go and Ruby language support.
\- More Vim/Neovim keybind parity, including
ZZ, visual block insert/append, window movement/resizing, and normal-mode Enter behavior. \- Labeled jump navigation with
:Jump / <Space>j, similar in spirit to leap/flash-style movement. \- Project-wide find and replace with a preview before applying changes.
\- nevi view, nevi diff, and nevi pick CLI modes.
\- Better
:checkhealth reporting for config, keymaps, LSP/tool setup, and performance diagnostics. \- A Vim oracle test harness and render regression tests to catch regressions earlier.
\- macOS/Linux CI and Homebrew install/update docs.
Install on macOS with Homebrew:
`brew install anthonyamaro15/nevi/nevi`
Repo: https://github.com/anthonyamaro15/nevi
Old post for more context: https://www.reddit.com/r/rust/comments/1u7qwbm/im\_building\_nevi\_a\_terminal\_editor\_in\_rust\_for/
It’s still early, but it’s getting closer to the editor I wanted: Vim-like editing without spending a bunch of time maintaining editor config.
If you try it, I’d especially love feedback on which Vim/Neovim keybinds or editing behaviors your hands expect that still don’t work yet.
https://redd.it/1uph0l2
@r_rust
GitHub
GitHub - anthonyamaro15/nevi: Fast terminal editor inspired by Neovim and Zed, written in Rust
Fast terminal editor inspired by Neovim and Zed, written in Rust - anthonyamaro15/nevi
Need help with AI anxiety
I know here ai posts are disliked but i really need help and just thoughts from more experienced people. I'm still a student with 2 years before graduation with great passion for systems programming especially operating systems and been learning them for a while now and of course, rust has been a joy to learn and use, but recently I just found myself unmotivated, I feel like, what if AI get much better than what it is now, with fable and that shit. and what if they focus more on optimizing that it start costing way cheaper, i feel lost, unmotivated, asking myself what's the point if all my skills and study time became worthless.. especially that i have adhd and i really love and hyperfocus on things that i love, and thinking about switching career feels like torture to me, not that i financially can but even if i could it would be miserable.. I just wish llms never existed.
https://redd.it/1upkllr
@r_rust
I know here ai posts are disliked but i really need help and just thoughts from more experienced people. I'm still a student with 2 years before graduation with great passion for systems programming especially operating systems and been learning them for a while now and of course, rust has been a joy to learn and use, but recently I just found myself unmotivated, I feel like, what if AI get much better than what it is now, with fable and that shit. and what if they focus more on optimizing that it start costing way cheaper, i feel lost, unmotivated, asking myself what's the point if all my skills and study time became worthless.. especially that i have adhd and i really love and hyperfocus on things that i love, and thinking about switching career feels like torture to me, not that i financially can but even if i could it would be miserable.. I just wish llms never existed.
https://redd.it/1upkllr
@r_rust
Reddit
From the rust community on Reddit
Explore this post and more from the rust community
maudio - all you need audio in one (miniaudio)
For a while now I've been working on maudio and it's very close to a complete interface to miniaudio.
maudio
Miniaudio is a very large audio C library, mainly aimed at game engines, but has pretty much everything you would need for audio. I think discord also uses(used?) it.
Initially, I wanted wanted to only grow it enough so I can make my own audio app with it, but lost interest in that as this was pretty fun. Even found a null ptr dereference bug in miniaudio along the way.
Maudio is technically just ffi library, but it's offers a completely safe interface to the audio tools that miniaudio has, including custom nodes, custom data sources and data source chaining. I want to eventually also offer a safe(ish?) interface for custom backends as well. It's rather large now, but I did my best to document it and write examples, more to be added.
There is both a low and high level API. The high level API mostly centers around an Engine, which contains a node graph with nodes of various function, a low level device and a resource manager that can reference count loaded audio. This is the 'just play this sound' route.
The low level API uses the low level device directly which supports playback, capture, duplex and loopback.
There's also an encoder, decoder, mixing, many dsp primitives, pcm audio buffer / thread safe ring-buffer, noise, pulse and wave generators, device enumeration, backend selection, raw audio callbacks and some things that I forgot about.
Next on my todo list is to allow using a pre-compiled miniaudio binary, and maybe ship some optional pre-compiled binaries myself.
I also started drafting a version built on top where all types are Send + Sync and Clone (control thread + queue model), but that will likely be a separate crate as things got a bit out of control (see rustjerk)
I'd love to hear some thoughts if anyone has interest in audio.
https://redd.it/1uppdmg
@r_rust
For a while now I've been working on maudio and it's very close to a complete interface to miniaudio.
maudio
Miniaudio is a very large audio C library, mainly aimed at game engines, but has pretty much everything you would need for audio. I think discord also uses(used?) it.
Initially, I wanted wanted to only grow it enough so I can make my own audio app with it, but lost interest in that as this was pretty fun. Even found a null ptr dereference bug in miniaudio along the way.
Maudio is technically just ffi library, but it's offers a completely safe interface to the audio tools that miniaudio has, including custom nodes, custom data sources and data source chaining. I want to eventually also offer a safe(ish?) interface for custom backends as well. It's rather large now, but I did my best to document it and write examples, more to be added.
There is both a low and high level API. The high level API mostly centers around an Engine, which contains a node graph with nodes of various function, a low level device and a resource manager that can reference count loaded audio. This is the 'just play this sound' route.
The low level API uses the low level device directly which supports playback, capture, duplex and loopback.
There's also an encoder, decoder, mixing, many dsp primitives, pcm audio buffer / thread safe ring-buffer, noise, pulse and wave generators, device enumeration, backend selection, raw audio callbacks and some things that I forgot about.
Next on my todo list is to allow using a pre-compiled miniaudio binary, and maybe ship some optional pre-compiled binaries myself.
I also started drafting a version built on top where all types are Send + Sync and Clone (control thread + queue model), but that will likely be a separate crate as things got a bit out of control (see rustjerk)
I'd love to hear some thoughts if anyone has interest in audio.
https://redd.it/1uppdmg
@r_rust
Reddit
From the rustjerk community on Reddit: I have become the inner joke
Explore this post and more from the rustjerk community
Together for a healthier Clippy (Rust Inside Blog)
https://blog.rust-lang.org/inside-rust/2026/07/06/unite-for-clippy/
https://redd.it/1upqc5x
@r_rust
https://blog.rust-lang.org/inside-rust/2026/07/06/unite-for-clippy/
https://redd.it/1upqc5x
@r_rust
blog.rust-lang.org
Together for a healthier Clippy | Inside Rust Blog
Want to follow along with Rust development? Curious how you might get involved? Take a look!
OUROBOROS-UI: The shadcn/ui design language rebuilt natively for egui! With governance tests that fail the build if a raw value bypasses the tokens
Hi r/rust! I've been building an MMO authoring IDE in egui and needed a real design system for it — so I built one, and today I'm open-sourcing it.
What it is: the shadcn/ui design language (semantic tokens, zinc aesthetic, 4px scale) reimplemented natively for egui.
Not a web port 60+ components (atoms → cells → molecules → organisms, plus a node-editor graph layer), all token-first.
The part I care most about: two governance tests run with cargo test and in CI:
- no_raw_values — a literal color, font size or spacing anywhere above the token layer fails the build
- no_painter_in_molecules — atoms are the only layer allowed to touch the painter
My take after years doing design systems at Dell/IBM: a design system only holds if the build enforces it. Conventions drift; compilers don't.
\- Live storybook (wasm): https://ouroboros-ui.typezerolabs.com/storybook/
\- Docs: https://ouroboros-ui.typezerolabs.com
\- Repo (MIT): https://github.com/Type-zero-labs/ouroboros-ui
API is pre-1.0 and evolving with the IDE. Feedback very welcome, especially from anyone who's fought egui theming at scale.
https://redd.it/1uptp3q
@r_rust
Hi r/rust! I've been building an MMO authoring IDE in egui and needed a real design system for it — so I built one, and today I'm open-sourcing it.
What it is: the shadcn/ui design language (semantic tokens, zinc aesthetic, 4px scale) reimplemented natively for egui.
Not a web port 60+ components (atoms → cells → molecules → organisms, plus a node-editor graph layer), all token-first.
The part I care most about: two governance tests run with cargo test and in CI:
- no_raw_values — a literal color, font size or spacing anywhere above the token layer fails the build
- no_painter_in_molecules — atoms are the only layer allowed to touch the painter
My take after years doing design systems at Dell/IBM: a design system only holds if the build enforces it. Conventions drift; compilers don't.
\- Live storybook (wasm): https://ouroboros-ui.typezerolabs.com/storybook/
\- Docs: https://ouroboros-ui.typezerolabs.com
\- Repo (MIT): https://github.com/Type-zero-labs/ouroboros-ui
API is pre-1.0 and evolving with the IDE. Feedback very welcome, especially from anyone who's fought egui theming at scale.
https://redd.it/1uptp3q
@r_rust
Typezerolabs
ouroboros-ui — live storybook
Live storybook of ouroboros-ui: the shadcn/ui design language native in Rust/egui, running in your browser via WebAssembly.
Maintainer spotlight: Gen Li (@rami3l)
https://blog.rust-lang.org/inside-rust/2026/07/07/maintainer-spotlight-gen-li-rami3l/
https://redd.it/1upwm2j
@r_rust
https://blog.rust-lang.org/inside-rust/2026/07/07/maintainer-spotlight-gen-li-rami3l/
https://redd.it/1upwm2j
@r_rust
blog.rust-lang.org
Maintainer spotlight: Gen Li (@rami3l) | Inside Rust Blog
Want to follow along with Rust development? Curious how you might get involved? Take a look!
I Ported My Browser Game from TypeScript to Rust and Bevy - My Thoughts and Performance Comparison
https://redd.it/1upwqf1
@r_rust
https://redd.it/1upwqf1
@r_rust
DKIM2 is now supported by the mail-auth and mail-send crates
For those not familiar with email internals, DKIM2 is the next iteration of DKIM, the email signing scheme that lets a domain cryptographically vouch for a message. The problem with DKIM1 is that a signature only covers content, so the moment a mailing list or forwarder touches a message the signature breaks, and a signed message can be replayed to any number of other recipients. DKIM2 turns a signature into a link in a verifiable chain of custody: each hop that modifies a message records a reversible "recipe" for its change and adds its own signature, the envelope (
DKIM2 support has been added to `mail-auth`, the Rust message authentication crate (it already does DKIM1, SPF, DMARC and ARC). The same release also implements DMARCbis (RFC 9989/9990/9991), the new DMARC standard that replaces the Public Suffix List with a live DNS tree walk.
If you want to see how DKIM2 actually behaves, there's a playground at mail-auth.stalw.art. It's the crate itself compiled to WebAssembly, running entirely in your browser and using DNS-over-HTTPS to resolve keys and validate signatures, so you can sign and verify DKIM2 messages and run DMARCbis checks with nothing to install.
If you don't care about the low-level details and just want to send DKIM2-signed email, `mail-send` integrates
For a more technical write-up of what DKIM2 and DMARCbis change and why, take a look at the blog post.
Feedback and bug reports welcome!
https://redd.it/1upxbcw
@r_rust
For those not familiar with email internals, DKIM2 is the next iteration of DKIM, the email signing scheme that lets a domain cryptographically vouch for a message. The problem with DKIM1 is that a signature only covers content, so the moment a mailing list or forwarder touches a message the signature breaks, and a signed message can be replayed to any number of other recipients. DKIM2 turns a signature into a link in a verifiable chain of custody: each hop that modifies a message records a reversible "recipe" for its change and adds its own signature, the envelope (
MAIL FROM/RCPT TO) is signed so replays no longer validate, and bounces can prove they're genuine. It's a fairly big rethink of how email authentication works.DKIM2 support has been added to `mail-auth`, the Rust message authentication crate (it already does DKIM1, SPF, DMARC and ARC). The same release also implements DMARCbis (RFC 9989/9990/9991), the new DMARC standard that replaces the Public Suffix List with a live DNS tree walk.
If you want to see how DKIM2 actually behaves, there's a playground at mail-auth.stalw.art. It's the crate itself compiled to WebAssembly, running entirely in your browser and using DNS-over-HTTPS to resolve keys and validate signatures, so you can sign and verify DKIM2 messages and run DMARCbis checks with nothing to install.
If you don't care about the low-level details and just want to send DKIM2-signed email, `mail-send` integrates
mail-auth behind a much simpler API.For a more technical write-up of what DKIM2 and DMARCbis change and why, take a look at the blog post.
Feedback and bug reports welcome!
https://redd.it/1upxbcw
@r_rust
GitHub
GitHub - stalwartlabs/mail-auth: DKIM, ARC, SPF and DMARC library for Rust
DKIM, ARC, SPF and DMARC library for Rust. Contribute to stalwartlabs/mail-auth development by creating an account on GitHub.
A standalone MVCC engine for transactional storage systems in Rust
We're open-sourcing **nexir-mvcc-core**, the transactional MVCC engine that powers the Nexir database.
The project focuses exclusively on concurrency control and version management, keeping storage, networking, consensus, and query execution outside the MVCC layer. It provides:
* Timestamp-ordered MVCC reads and writes
* Intent-based transactions (`prewrite` / `commit` / `abort`)
* Atomic multi-key batch transactions
* Guarded (CAS-style) writes
* Incremental MVCC garbage collection
* A backend abstraction that allows integration with different storage engines
* Backend conformance testing utilities
The goal is to provide a deterministic, reusable MVCC core that can serve as the foundation for transactional storage systems without requiring an entire database stack.
We're interested in feedback from Rust developers working on databases, storage engines, distributed systems, or transactional KV stores.
GitHub: [https://github.com/nexirdb/nexir-mvcc-core](https://github.com/nexirdb/nexir-mvcc-core)
Happy to answer questions about the architecture and design decisions.
https://redd.it/1uq204t
@r_rust
We're open-sourcing **nexir-mvcc-core**, the transactional MVCC engine that powers the Nexir database.
The project focuses exclusively on concurrency control and version management, keeping storage, networking, consensus, and query execution outside the MVCC layer. It provides:
* Timestamp-ordered MVCC reads and writes
* Intent-based transactions (`prewrite` / `commit` / `abort`)
* Atomic multi-key batch transactions
* Guarded (CAS-style) writes
* Incremental MVCC garbage collection
* A backend abstraction that allows integration with different storage engines
* Backend conformance testing utilities
The goal is to provide a deterministic, reusable MVCC core that can serve as the foundation for transactional storage systems without requiring an entire database stack.
We're interested in feedback from Rust developers working on databases, storage engines, distributed systems, or transactional KV stores.
GitHub: [https://github.com/nexirdb/nexir-mvcc-core](https://github.com/nexirdb/nexir-mvcc-core)
Happy to answer questions about the architecture and design decisions.
https://redd.it/1uq204t
@r_rust
GitHub
GitHub - nexirdb/nexir-mvcc-core: Standalone, deterministic MVCC engine for building transactional key-value databases in Rust…
Standalone, deterministic MVCC engine for building transactional key-value databases in Rust — timestamp-ordered versions, two-phase intent transactions, guarded writes, and incremental GC. The ope...
Is there a CSV search crate yet?
What I am looking for is like binary search or faster of a CSV file for IP addresses, does something like this exist yet or not? Not MaxMindDB, CSV, more free stuff is CSV, so?
https://redd.it/1uqach6
@r_rust
What I am looking for is like binary search or faster of a CSV file for IP addresses, does something like this exist yet or not? Not MaxMindDB, CSV, more free stuff is CSV, so?
https://redd.it/1uqach6
@r_rust
Reddit
From the rust community on Reddit
Explore this post and more from the rust community
Rust splits polymorphism into two completely separate design choices
Coming from a traditional object-oriented background (Java/C#), inheritance gave me polymorphism. You create a base class, extend it, throw your subclasses into a contiguous array, and call it a day. When you migrate to Rust, inheritance disappears. But instead of leaving an architectural void, Rust actually splits polymorphism into two entirely separate, highly intentional design strategies based on your data layout boundaries:
1. Closed Polymorphism (Compile-time completeness)
This is where your types are strictly locked down at compile time, typically using uniform-sized Enums.
The Trade-off: The compiler calculates the exact footprint of your largest variant, adds a small tag, and sets up a flat block of stack memory. It is blazing fast and gives compile-time guarantees that every variant is accounted for.
The Catch: If you want to add a type later, you have to modify the central definition. It entirely prevents third-party modular extension.
2. Open Polymorphism (Infinite extensibility)
This is what we step into when we use dynamic dispatch, vtables, and heap-allocated Boxed Trait Objects.
The Trade-off: You can drop in entirely new data types from separate, external third-party crates next week without touching a single line of your core engine code.
The Catch: You give up data uniformity, force pointer-heavy allocations onto the heap, and pay a tiny dynamic dispatch tax.
To map this out practically, I used both strategies to build character types for a game backend. Coming from an OOP background, my first attempt at the closed solution with Enums resulted in massive data duplication and tons of repetitive match-statement boilerplate.
I ended up solving the data clunkiness by forcing Composition over Inheritance—separating shared stats into a standard struct, variant-specific data into an enum, and wrapping them both in a parent struct. This kept my storage in a perfectly flat Vec while letting me read common fields cleanly without paying an access tax.
However, the moment I wanted to let third-party modders add custom player types, my beautiful closed enum solution hit a hard, unyielding structural wall.
For those writing large-scale systems in Rust, how do you map out this boundary early on? Do you find yourself defaulting to enums for performance until requirements force you onto the heap, or do you architect for open extension from day one?
Context: I run a channel focused on software engineering in Rust using high-fidelity animations to trace memory footprints and system boundaries. If you want to see a visual breakdown of this exact Closed vs. Open memory model and the refactoring step-by-step, check it out here: https://youtu.be/l\_q9U10JueE (Full code for the closed, open, and hybrid implementations is over on the GitHub linked in the description).
https://redd.it/1uqgk6t
@r_rust
Coming from a traditional object-oriented background (Java/C#), inheritance gave me polymorphism. You create a base class, extend it, throw your subclasses into a contiguous array, and call it a day. When you migrate to Rust, inheritance disappears. But instead of leaving an architectural void, Rust actually splits polymorphism into two entirely separate, highly intentional design strategies based on your data layout boundaries:
1. Closed Polymorphism (Compile-time completeness)
This is where your types are strictly locked down at compile time, typically using uniform-sized Enums.
The Trade-off: The compiler calculates the exact footprint of your largest variant, adds a small tag, and sets up a flat block of stack memory. It is blazing fast and gives compile-time guarantees that every variant is accounted for.
The Catch: If you want to add a type later, you have to modify the central definition. It entirely prevents third-party modular extension.
2. Open Polymorphism (Infinite extensibility)
This is what we step into when we use dynamic dispatch, vtables, and heap-allocated Boxed Trait Objects.
The Trade-off: You can drop in entirely new data types from separate, external third-party crates next week without touching a single line of your core engine code.
The Catch: You give up data uniformity, force pointer-heavy allocations onto the heap, and pay a tiny dynamic dispatch tax.
To map this out practically, I used both strategies to build character types for a game backend. Coming from an OOP background, my first attempt at the closed solution with Enums resulted in massive data duplication and tons of repetitive match-statement boilerplate.
I ended up solving the data clunkiness by forcing Composition over Inheritance—separating shared stats into a standard struct, variant-specific data into an enum, and wrapping them both in a parent struct. This kept my storage in a perfectly flat Vec while letting me read common fields cleanly without paying an access tax.
However, the moment I wanted to let third-party modders add custom player types, my beautiful closed enum solution hit a hard, unyielding structural wall.
For those writing large-scale systems in Rust, how do you map out this boundary early on? Do you find yourself defaulting to enums for performance until requirements force you onto the heap, or do you architect for open extension from day one?
Context: I run a channel focused on software engineering in Rust using high-fidelity animations to trace memory footprints and system boundaries. If you want to see a visual breakdown of this exact Closed vs. Open memory model and the refactoring step-by-step, check it out here: https://youtu.be/l\_q9U10JueE (Full code for the closed, open, and hybrid implementations is over on the GitHub linked in the description).
https://redd.it/1uqgk6t
@r_rust
YouTube
Polymorphism Without Inheritance: The Power of Rust Enums
When object-oriented programmers migrate to Rust, one of the first brick walls they hit is collection uniformity. In languages with inheritance, grouping different objects into a single array is trivial—you just create a list of the parent base class. But…
Is it tauri good for cross platform apps?
My goal is to create a cross platform app using Tauri with rust. On the front and side, I'm planning to use react with a typescript and on the backend well, of course, rust. However I am not so sure if Tauri is a great choice for Android apps, given the fact that Tauri uses webview to render apps.
I want to make it feel lightweight and with a small size overall. My focus is Linux, Windows and Android, my primary OSs that I use. I know for desktop apps is ok, but when it comes to desktop AND Android apps I am not sure if performance could be harmed or even impossible to do.
I just finished the rust book so you could say that I am new to rust and this would also be my first cross platform app outside webdev (granted: tauri uses webview and I planing to use web technologies, but still, it feels like another world). I am doing my research but any guidance would also be pretty much appreciated.
PD: For more context, it is a document viewer, like a pdf and epub viewer.
https://redd.it/1uqad41
@r_rust
My goal is to create a cross platform app using Tauri with rust. On the front and side, I'm planning to use react with a typescript and on the backend well, of course, rust. However I am not so sure if Tauri is a great choice for Android apps, given the fact that Tauri uses webview to render apps.
I want to make it feel lightweight and with a small size overall. My focus is Linux, Windows and Android, my primary OSs that I use. I know for desktop apps is ok, but when it comes to desktop AND Android apps I am not sure if performance could be harmed or even impossible to do.
I just finished the rust book so you could say that I am new to rust and this would also be my first cross platform app outside webdev (granted: tauri uses webview and I planing to use web technologies, but still, it feels like another world). I am doing my research but any guidance would also be pretty much appreciated.
PD: For more context, it is a document viewer, like a pdf and epub viewer.
https://redd.it/1uqad41
@r_rust
Reddit
From the rust community on Reddit
Explore this post and more from the rust community
How do people feel about AI being used in the core language?
I know this is Reddit, but I would like to preface this by saying that I'm interested in having a balanced and reasoned discussion with other rustaceans about their feelings regarding AI commits in the core language, and how they think it might impact their choice of programming language in the future.
With that out of the way, how do you feel about Generative AI being used in the core language, and the rust foundation accepting donations from AI companies? Personally, I don't like AI. Not through some aversion to new technology (rust is my language of choice, after all), but because I have no desire to use something with so many unanswered ethical questions (environmental impact, training on stolen data, reinforcement of existing biases etc) in my processes. This is not a binary black and white stance, but a desire to minimize my impact where I can.
Rust has long been my favourite programming language. It's fast, comes out well in energy usage benchmarks, and the compiler makes me feel a lot more confident in the code I write. However, the official position of the rust foundation is very pro AI. They've accepted large donations from OpenAI, and there have now been commits to the core language that have used AI to a certain extent.
This leaves me with a conundrum. Overall, I feel that Generative AI is rapidly making the digital world a worse place (we're drowning in slop) and I want to avoid that as much as I can. Do I stick to an older version of Rust? Do I move to another language like Zig that has an anti-AI stance (impressed by that, not impressed by much else that I've heard from the main developer)? Do I try and fork the language myself knowing that I lack the knowledge or time to do anything more with it than make a statement?
I'm still not decided yet, but would be very curious to hear if others are currently contemplating similar choices, and what your feelings are on the matter.
https://redd.it/1uqm388
@r_rust
I know this is Reddit, but I would like to preface this by saying that I'm interested in having a balanced and reasoned discussion with other rustaceans about their feelings regarding AI commits in the core language, and how they think it might impact their choice of programming language in the future.
With that out of the way, how do you feel about Generative AI being used in the core language, and the rust foundation accepting donations from AI companies? Personally, I don't like AI. Not through some aversion to new technology (rust is my language of choice, after all), but because I have no desire to use something with so many unanswered ethical questions (environmental impact, training on stolen data, reinforcement of existing biases etc) in my processes. This is not a binary black and white stance, but a desire to minimize my impact where I can.
Rust has long been my favourite programming language. It's fast, comes out well in energy usage benchmarks, and the compiler makes me feel a lot more confident in the code I write. However, the official position of the rust foundation is very pro AI. They've accepted large donations from OpenAI, and there have now been commits to the core language that have used AI to a certain extent.
This leaves me with a conundrum. Overall, I feel that Generative AI is rapidly making the digital world a worse place (we're drowning in slop) and I want to avoid that as much as I can. Do I stick to an older version of Rust? Do I move to another language like Zig that has an anti-AI stance (impressed by that, not impressed by much else that I've heard from the main developer)? Do I try and fork the language myself knowing that I lack the knowledge or time to do anything more with it than make a statement?
I'm still not decided yet, but would be very curious to hear if others are currently contemplating similar choices, and what your feelings are on the matter.
https://redd.it/1uqm388
@r_rust
This media is not supported in your browser
VIEW IN TELEGRAM
broadsheet: a Rust animation engine where the whole video is a pure function of time — tech demo (binary search, hash rings, union-find)
https://redd.it/1uqn0bm
@r_rust
https://redd.it/1uqn0bm
@r_rust
Still surprised by how helpful Rust's compiler is
I've been spending more time learning Rust lately, and one thing that keeps surprising me is the compiler.
At first it felt like it was constantly telling me I was doing everything wrong. But after sticking with it for a while, I realized most of the error messages are actually pointing me in the right direction instead of just saying "this doesn't work."
I'm definitely still a beginner, but I've had several moments where I fixed a bug simply by following what the compiler was trying to tell me.
Did anyone else have that moment where Rust's compiler went from feeling like an obstacle to feeling like a really patient mentor? I'm curious how long that shift took for others.
https://redd.it/1uqpppm
@r_rust
I've been spending more time learning Rust lately, and one thing that keeps surprising me is the compiler.
At first it felt like it was constantly telling me I was doing everything wrong. But after sticking with it for a while, I realized most of the error messages are actually pointing me in the right direction instead of just saying "this doesn't work."
I'm definitely still a beginner, but I've had several moments where I fixed a bug simply by following what the compiler was trying to tell me.
Did anyone else have that moment where Rust's compiler went from feeling like an obstacle to feeling like a really patient mentor? I'm curious how long that shift took for others.
https://redd.it/1uqpppm
@r_rust
Reddit
From the rust community on Reddit
Explore this post and more from the rust community
memegen.rs - a meme generator where the entire meme is the URL (no database, ~1900 lines of Rust)
https://preview.redd.it/d9b3rj1b60ch1.png?width=675&format=png&auto=webp&s=d0d7bbb2d1bb3347ffe2f3580b2e1f9df87ae11a
The image above was rendered by the thing itself. This is its entire existence:
https://memegen.rs/images/bell-curve/just_put_the_meme_in_the_url/no,_you_need_postgres,_redis,_s3,_a_cdn,_and_auth/just_put_the_meme_in_the_url.png
That URL is the whole meme: template id, then one path segment per caption box, spaces as underscores. No database, no cache server, no accounts - every image is rendered on demand from the URL alone, so any meme is shareable and reproducible forever.
It's a reimplementation of [jacebrowning/memegen](https://github.com/jacebrowning/memegen) (the Python service behind memegen.link). Stack: `axum` for HTTP, `image`/`imageproc`/`ab_glyph` for rendering (caption autosizing, word wrap, outlined text, animated GIFs), `maud` for a compile-time-checked web UI. 1924 lines across three source files, 701 templates bundled, fonts embedded with `include_bytes!`, `unsafe_code = "forbid"`. The deployment is one binary plus a directory of template folders.
Deploying it was its own adventure: it runs as a Cloudflare Container that scales to zero when idle, with a Worker in front caching rendered images at the edge, so cache hits never touch the Rust process. Two gotchas for anyone trying the same: Cloudflare's registry can't pull from GHCR, and it rejects the `latest` tag.
A side effect of the API being nothing but URLs: agents can use it with zero setup - there's a drop-in skill file at [memegen.rs/skill.md](https://memegen.rs/skill.md) (and `/llms.txt`).
Repo: [github.com/tenequm/memegen-rs](https://github.com/tenequm/memegen-rs) \- code is MIT, the bundled template images aren't (see README)
Live: [memegen.rs](https://memegen.rs)
Since a meme is just a URL, it works anywhere you can paste a link - Reddit comments included. Template id, caption in the path, done. All 701 templates are in the gallery at [memegen.rs](https://memegen.rs).
https://redd.it/1uqrvfb
@r_rust
https://preview.redd.it/d9b3rj1b60ch1.png?width=675&format=png&auto=webp&s=d0d7bbb2d1bb3347ffe2f3580b2e1f9df87ae11a
The image above was rendered by the thing itself. This is its entire existence:
https://memegen.rs/images/bell-curve/just_put_the_meme_in_the_url/no,_you_need_postgres,_redis,_s3,_a_cdn,_and_auth/just_put_the_meme_in_the_url.png
That URL is the whole meme: template id, then one path segment per caption box, spaces as underscores. No database, no cache server, no accounts - every image is rendered on demand from the URL alone, so any meme is shareable and reproducible forever.
It's a reimplementation of [jacebrowning/memegen](https://github.com/jacebrowning/memegen) (the Python service behind memegen.link). Stack: `axum` for HTTP, `image`/`imageproc`/`ab_glyph` for rendering (caption autosizing, word wrap, outlined text, animated GIFs), `maud` for a compile-time-checked web UI. 1924 lines across three source files, 701 templates bundled, fonts embedded with `include_bytes!`, `unsafe_code = "forbid"`. The deployment is one binary plus a directory of template folders.
Deploying it was its own adventure: it runs as a Cloudflare Container that scales to zero when idle, with a Worker in front caching rendered images at the edge, so cache hits never touch the Rust process. Two gotchas for anyone trying the same: Cloudflare's registry can't pull from GHCR, and it rejects the `latest` tag.
A side effect of the API being nothing but URLs: agents can use it with zero setup - there's a drop-in skill file at [memegen.rs/skill.md](https://memegen.rs/skill.md) (and `/llms.txt`).
Repo: [github.com/tenequm/memegen-rs](https://github.com/tenequm/memegen-rs) \- code is MIT, the bundled template images aren't (see README)
Live: [memegen.rs](https://memegen.rs)
Since a meme is just a URL, it works anywhere you can paste a link - Reddit comments included. Template id, caption in the path, done. All 701 templates are in the gallery at [memegen.rs](https://memegen.rs).
https://redd.it/1uqrvfb
@r_rust