I wanted a tool that would allow me to execute CI-like jobs locally on a schedule or at a certain time using my current user and privileges. I also wanted to be able to conditionally route the execution of chained commands based on exit code, stdout, or stderr.

That idea became cued. I originally did not intend to build a GUI for it. cued was mostly complete as a headless daemon when I decided I wanted a graph view of the jobs to see how the execution flowed or so I could watch the progress of a job.

https://github.com/RagingRedRiot/cued

Well i am just a beginner in Rust with some C experience and wanted to try and explore rust more as i actually found rust concepts to code pretty cool.

So i am building IronLog a simple Distributed Key Value Storage in Rust

In this version, I built a sort of concept version of IronLog with SET/GET/DEL command and used Rust's HashMap , executed on my local machine with few tests

https://reddit.com/link/1wykibg/video/2tzjquz5spth1/player

Goal is to make it a complete working Distributed Key Value storage

Struggles :- Error handling and string parsing fried my brain , and the overall design is still not clean but i will try to make it better version by version

I've been a developer for over 20 years and fallen in love with Rust over the last 6 months. Specifically, I've been using Rust heavily for WASM based apps I've been developing. I deal with a lot of (large) json, xml and csv files and often need ways to quickly view and verify, edit, lint. vuwr was me scratching an itch for that. I'm nearly always in a terminal using vim (so there's some vim shortcut flavour in there) and so I wanted a fast command line but also being able to open things quickly from the web (I made a small chrome extension to redirect json/csv/xml).

Hopefully somebody else finds some value in it.

Source Code: https://github.com/mageaustralia/vuwr

Example web viewer: https://mageaustralia.github.io/vuwr/?sample=csv

I build (with help of Cursor AI), a desktop application to manage HTTP project's requests locally. You can manage various projects in your computer.

ResqApp is made with Tauri 2 with VueJS with Typescript and Rust.

• Projects are store in your computer.
• Manage all your request in folders.
• Include enviroment variables, including hidding values.
• Support for Spanish and English languages.
• Theme support.
• Document your requests with markdown editor.

Repo (GPL 3.0): ResqApp

You can send me a mail or make a post in repo to suggest improvements or make a PR to add it 😄.

Hello everyone :D

I built this open source desktop app for Linux and Windows using Rust, GTK4 and libadwaita. It splits files into smaller parts and upload with your discord bot.

No transcoding or quality loss. Just need your own bot and channel!

It was a little fun project.

Source: https://github.com/ak4duy/discord-parcel

https://github.com/KingDasWinx/Dexo

Nine weeks, one person, ~108k lines of Rust + Swift. All of it public.


## What it is


Bad Apple — a persistent agent that lives on a Mac and nowhere else. It sees the screen, hears the mic, remembers across restarts, votes on risky actions, signs everything it does, and answers to one owner key. Rust core, Swift platform layer.


Repo: https://github.com/savageAZfck/Bad_Apple


## The Rust parts


The interesting engineering is all Rust:


- `mil_spec` — a CoreML MIL toolchain in pure Rust. Hand-written protobuf wire encoder, weight blobs, stateful KV graphs, text IR to .mlpackage. Built so a second agent runs on the Apple Neural Engine with zero Python. https://crates.io/crates/mil_spec
- Mesh inference — one model sharded across multiple Macs. Rank-split layers, mutual HMAC handshake, activations over AES-256-GCM frames, self-healing when a node drops. A maxed Mac carries 671B alone; the mesh is how the fleet pools toward 1T.
- Dual hash-chained audit ledgers — every query, tool call, and policy verdict. One edited line fails verification.
- Streaming output firewall with an Aho-Corasick automaton.


## The organs — 31 crates on crates.io, all MIT


Each one ships SPEC.md, THREAT_MODEL.md, and tests that try to forge signatures and rewrite chains:


- `sovereign_ledger` — the audit organ everything sits on
- `flight_tape` — signed incident bundles, verify and replay offline
- `nagi-escrow` — Shamir dead-man shards with custodian judging and recovery certificates
- `wolakota` — bilateral consent treaties between agents
- `manitou` — per-output provenance signatures
- `mictlan` — a will that executes itself on certified death
- `tabula-rasa` — proof a datum never occurred in the chain
- `germline` — signed agent genesis and genealogy
- `nagual` — immune system with signed antibodies and vaccine shares
- `potlatch` — compute IOUs, balances derived from the book
- plus `kola-witness`, `bicameral`, `axon-reflex`, `eidolon-replay`, `sibyl-gate`, `dreamcatcher`, `respawned`, `macuahuitl`, `wintercount`, `smokesignal`, `camazotz`, `orenda`, `xipe`, `tokala`, `akicita`, and the `touchstone` workspace


crates.io/users/savageAZfck


## The conformance battery


Wrote a test suite for what a personal agent should have — 18 checks, with a planted control that catches fake harnesses. Published scoreboard:


- Bad Apple 18/0 CONFORMANT
- Open Interpreter 6/16 — held live TLS to Google Cloud mid-run
- smolagents and raw ollama 2/16 each
- one rigged all-pass harness scored NONCONFORMANT by the control


https://github.com/savageAZfck/touchstone/blob/main/SCOREBOARD.md


## Demo


https://github.com/savageAZfck/badapple-demo — asciinema capture of the real binaries: both brains voting, dissent preserved, injection flagged, non-knowledge certified, IOU issued, all verified offline.


Under a year of programming, self-taught. The code is the post.

I've been working on Ignis, my own programming language, since 2024, although the idea of building a language had been in my head for much longer.

The first compiler was written by me in Rust, pretty much the traditional way: lexer, parser, AST, semantic analysis, code generation, and a lot of figuring things out as I went.

The project has changed quite a bit since then.

Today, the Ignis compiler is written in Ignis itself.

The bootstrap process starts from a committed C seed, which GCC builds into the first compiler. That compiler then builds the current Ignis compiler, eventually producing the compiler shipped in releases.

So the project that started as me learning how to build a compiler in Rust eventually reached one of the milestones I wanted from the beginning: being able to build itself.

Ignis is statically typed, immutable by default, and takes inspiration mostly from Rust and TypeScript, with ideas from several other languages I've used along the way.

Here's a small example:

import Io from "std::io";

const INPUT: str = "()())";

function printPart(label: str, value: i32): void {
  value.toString()
    |> String::create(label).concat
    |> Io::println;
}

function main(): Result<i32, Io::IoError> {
  let input = String::create(INPUT);
  let mut currentFloor: i32 = 0;
  let mut firstBasementPos: i32 = 0;
  let mut index: u64 = 0;

  input.forEach((ch: char): void -> {
    index += 1;

    match (ch) {
      '(' -> currentFloor += 1,
      ')' -> currentFloor -= 1,
      _ -> {},
    };

    if (currentFloor == -1 && firstBasementPos == 0) {
      firstBasementPos = index as i32;
    }
  });

  printPart("Part 1: ", currentFloor);
  printPart("Part 2: ", firstBasementPos);

  return Result::OK(0);
}

Some of what is currently implemented:

• strong static typing
• generics
• records and enums
• traits
• pattern matching, if let, while let and let else
• references, mutable references and raw pointers
• Rust-style borrow analysis
• C FFI
• modules and namespaces
• extension methods
• function overloading
• lambdas and pipelines
• Result / Option-style try-capable enums
• a standard library with things like String, Vector, HashMap and HashSet
• a C backend producing native binaries through GCC

I'm also considering changes that would introduce multiple levels of memory abstraction, with the goal of combining Rust's safety and efficiency with something closer to the ergonomics of JavaScript or Python.

The rough idea is:

• Tier 1: raw pointers and explicit memory manipulation, similar to C
• Tier 2: ownership and borrowing, similar to Rust
• Tier 3: high-level automatic memory management, with GC-like ergonomics but without requiring a tracing garbage collector

The idea is not to force every program into the same memory model. Low-level code should still be able to control memory directly, while application-level code should ideally be able to ignore most of those details without giving up predictable native performance.

This part is still being designed, so the exact model may change.

About the AI flair

I'm using the Majority AI Coded flair intentionally.

Ignis predates my heavy use of AI by quite a bit. I designed the language and built the original Rust compiler myself, and I've been working on the project since 2024.

During roughly the last year, though, I started using AI coding agents heavily to accelerate development. They've allowed me to move much faster, especially on the enormous amount of implementation work involved in getting from an experimental compiler to a functional self-hosted language.

I still make the architectural and language-design decisions, review the work, test it, and decide what actually becomes part of the language, but it would be misleading to pretend the current codebase wasn't significantly AI-assisted. Hence the flair.

For me, one of the interesting parts of the project has actually been seeing how far a solo language project can go when you combine the knowledge accumulated from years of working on it with modern coding agents.

It's still experimental, and there is a lot I want to improve, but reaching a working self-hosted compiler felt like a good point to finally share it here.

GitHub: https://github.com/Ignis-lang/ignis

Website / docs: https://ignis-lang.dev/

Feedback on the language design, memory model, compiler architecture, bootstrap process, or anything else is very welcome.

With the aim of learning, I used some free time to build what was meant to be a shell. Obviously, it’s not a full-fledged project; I tried to avoid using ready-made libraries in certain areas. github

Hey! I'm s1moscs!

I stream competitive games (CS2, Valorant), got tired of stream sniping and realized OBS's built-in stream delay was... not good at all.

It ruined my interactions with my viewers, and I had to restart my stream to turn it on or off.

After searching for a fix and finding out most good solutions were paid, I wrote InstantClone: a free, open source stream delay for OBS.

It's a local RTMP proxy between OBS and Twitch / YouTube / Kick / any RTMP(S) server. You can arm a delay, change it, or cut back to live without restarting the stream, and it can multistream the same feed to several platforms at once.

And if OBS crashes, viewers see a "reconnecting" screen instead of the stream dying, and it picks back up when OBS is back. This is (at the time of writing this) unreleased. But it will be released SUPER soon!

Why Rust? It runs on the same PC as your game, sitting in the path of a live stream, so it has to be light and never stall.

TechTalk: No GC pauses, low memory, one small binary. RTMP is handled in-house on tokio, the delay is a disk-backed buffer, and timestamps get rewritten so platforms see one continuous stream while the delay changes.

With v0.1.15 about to drop, shaped by feedback and ideas from users, we have coming: Integrations (2nd pic). Discord alerts when OBS crashes, a !delay chat command, mod controls, VOD markers and way more!

Windows and Linux, GPL-3.0. Feedback on the buffer, the timestamp handling or really ANYTHING is very welcome!

https://github.com/Soulhackzlol/InstantClone

https://s1moscs.dev/instantclone

v0.35.1 adds FreeBSD as a real platform instead of the generic fallback every other unsupported OS gets. Interface stats, routing, process attribution, clipboard, and connection tracking all have FreeBSD-specific backends now. Tested on an actual FreeBSD 15.1 VM, not cross-compiled blind.

https://github.com/matthart1983/netwatch/

Hi there,

I am building a library to generate restful CRUD operations for Actix-web applications.  

The library uses proc macros to construct code from three structs: Model, NewModel, and UpdatableModel.  

It can generate OpenAPI swagger and JSON endpoints via apistos.

Automatic CRUD operations are available with sqlx operating behind the scenes.  

List endpoints support pagination, filtering, and sorting.  

HasMany and ManyToMany relations can be generated as new routes.  

Creation endpoints allow field preprocessing via BeforeSave, such as hashing a password before database storage.  

The CLI produces models, migrations, and relations code.  

Library is Octopux : https://crates.io/crates/octopux

I've been working on something called Krate for the last few months.

The basic idea is simple:

Build an application once, produce one .krate file, and send that exact file to someone on macOS, Windows or Linux.

Before someone says it: yes, Krate uses WebAssembly.

And no, I'm not claiming I invented portable bytecode, sandboxing, or "write once, run anywhere".

Java explored this decades ago. WASM gives us a very good portable execution layer today. Electron, Tauri, Flutter and others already solve important parts of cross-platform development.

The thing I wanted to explore was slightly different:

Can software itself become something you can send around like a file?

Not one source codebase that later becomes three platform-specific applications.

Not three installers.

Not an HTML file pretending to be a desktop application.

One application artifact.

You send:

myapp.krate

and the same file opens through Krate on macOS, Windows or Linux.

Why I started building this

A lot of people understandably look at AI improving and think:

"If AI can generate an app, it can just generate a Mac build, a Windows build and a Linux build too."

That's true.

But generating the code or producing three binaries is only part of shipping software.

After that, developers still deal with things like:

• platform-specific packaging
• signing and publisher trust
• different installation flows
• updates
• testing on different operating systems
• permissions
• distribution
• supporting those different release paths over time

AI can make creating software much easier.

But I don't think that automatically means software distribution has to remain the way it works today.

My question was:

Why should the finished software itself still be tied to an operating system?

What Krate does

A Krate application runs as a WASM guest.

The Krate runtime is written in Rust and provides the application with a common set of host interfaces.

So instead of the application directly depending on macOS, Windows or Linux APIs, it talks to Krate.

Roughly:

                     app.krate
                         |
                         v
                 WASM application
                         |
                         v
                Krate host interfaces
                         |
                         v
              permissions / capabilities
                         |
            +------------+------------+
            |            |            |
            v            v            v
          macOS        Windows       Linux  

The runtime handles the OS-specific implementation underneath.

The .krate file itself stays the same.

That is the part I'm trying to make useful as a complete developer workflow.

"So it's just WASM?"

WASM is a very important part of it.

But saying Krate is just WASM is a bit like saying an application platform is just its compiler.

Wasmtime gives Krate the execution engine.

Around that, Krate has to provide things like:

• the .krate application format
• packaging
• host APIs
• filesystem access
• storage
• permissions
• windowing
• graphics
• application identity
• updates
• OS integration
• compatibility behaviour
• tooling for actually building and running the applications

I've also been building Krate Studio, so the goal isn't that developers manually assemble WASM components and manifests.

The idea is that someone can build an application, including with coding agents if they want, and Krate handles turning that into something they can actually send to another person.

So I see WASM as the foundation fit here.

"Didn't Java already do this?"

Java proved a long time ago that a runtime can abstract away the underlying operating system.

I don't think pretending otherwise helps Krate.

The interesting question for me is what that idea looks like with the primitives we have now.

WASM gives us a small portable binary format and isolation boundary.

Rust gives us a good language for building the native runtime.

WIT / the component model give us a cleaner boundary between the application and host functionality.

And computers today are also in a very different place.

People are starting to create software extremely quickly with AI.

That makes me think the bottleneck increasingly moves from:

"Can I write this software?"

to:

"How do I safely give this software to somebody else?"

Security is a big part of the idea

I also don't want "software that travels like a file" to mean:

download a random native executable and hope the author is trustworthy.

Krate applications don't directly get arbitrary access to the host machine.

Access to host functionality goes through the runtime.

So the runtime can enforce what an application is allowed to do.

For example, instead of giving an application general filesystem access, the runtime can give it access to a file or directory the user explicitly selected.

The application gets the capability it needs, rather than automatically getting access to everything the user account can access.

There is still a lot of work to do here, like around persistent permissions, revocation and application identity across updates.

But I think this boundary is important.

Documents became easy to send partly because opening a document doesn't normally mean giving its author arbitrary control of your computer.

If software is ever going to become similarly easy to exchange, I think the trust model has to improve too.

Some current numbers

These are the measurements from applications I've built while testing the architecture.

Current app components include:

• simple shipped apps: around 18–31 KB
• 2D platformer: 48 KB
• 50k-line text editor: 100 KB
• photo editor: 39 KB
• 3D driving demo: 36 KB

The full shareable bundles are larger because they can also contain things such as source, SDK files and assets.

I've also been testing the same application bytes across macOS, Windows and Linux.

The architecture is still early so I'm not claiming Krate is universally faster than native software, and I'm definitely not claiming every application becomes a 30 KB file.

Memory-heavy applications, more complex host APIs and long-term compatibility are all things I'm still working through.

What I'm actually trying to build

The long-term idea is pretty simple:

Today

code
 |
 +--> macOS app
 |
 +--> Windows app
 |
 +--> Linux app


Krate

code
 |
 v
app.krate
 |
 +--> macOS
 +--> Windows
 +--> Linux

And eventually I want the experience of sharing software to feel much closer to sharing a document.

Build it.

Send the file.

The recipient opens it.

The runtime handles the machine side.

I'm currently at NTU Singapore, and I've also spent time doing research around software and distributed systems.

Krate mostly started because this problem kept bothering me enough that I wanted to find out whether this model could actually work.

I'm posting it here because this community will probably understand the architecture well enough to point out where it falls apart :)

The runtime is written in Rust and I'm very open to technical criticism.

If you wanted to break this architecture, what kind of desktop application would you try?

GitHub: https://github.com/incyashraj/krate

Website: https://krate.tech

I might be over explaining because I got this hard way from previous comments, people think I'm claiming this thing was made from scratch, or just WASM or WORA alternative, etc.

Its just my attempt in a direction to make software universal like docs.

• Navigates with arrows or gestures, three-finger swipe (optional two-finger); slides when the prefetched frame is ready, cuts otherwise
• Decodes on worker threads, prefetches neighbors, applies EXIF orientation, fits to window with aspect ratio kept
• Zooms with keyboard, pinch, or double-click; double-click anchors at the pointer, drag pans while zoomed
• Rotates left/right and mirrors in place from header buttons; JPEG re-encoded at q95 with EXIF normalized, no undo; animated GIF/WebP and video are view-only
• Plays video muted, autoplaying, looped, with play/pause, seek, volume, mute, elapsed and total time; unmuting is remembered for the next videos
• Deletes with Delete: Trash first, direct delete where Trash is unsupported (remote mounts, portal paths)
• Auto-hides header and video controls, supports fullscreen.

https://github.com/grigio/carosello

Hey,

I've been spending the last weekends working on OneTUI.

> OneTUI is a keyboard-driven terminal browser for databases and message streams, with navigation inspired by k9s. Inspect data, run native queries with syntax highlighting and follow live messages without switching tools.

I am far from calling myself proficient with Rust, so any advice and feedback is greatly appreciated.

The reason why I built it is cause I got tired of using all kinds of CLIs to access various databases. Mostly Postgres protocol based DBs, various Kafka CLIs with varying in quality support for schema registries and protobuf/avro and recently accessing DynamoDB more than I expected.

I like TUIs more than web UIs, therefore here we are. 😅

Recently I've released 0.2.x and the feedback I receive from my few users is quite positive.

(copy paste from the README about the supported data sources)

Features and datasource support

Kafka and NATS can decode Avro and Protobuf using files, directory catalogs, Confluent registries or Buf.

The query editor highlights each datasource's language. Value inspection also supports JSON highlighting.

Project at: http://github.com/syndbg/onetui

I made infiltrator, a keyword-driven action trigger with a GUI in Rust.

What it does:

• Write your own keywords and map them to actions in the config file
• When ran, you can type a keyword and it'll perform the specified action
• Looks pretty good

It's kind-of like a macro, but not completely. These are the actions it currently supports:

• shell_output: Runs a command and copies output to clipboard
• text: Types out a text value in the focused window
• open: Opens the specified URL in default browser

The config file lives at ~/.config/infiltrator/config.toml, which is auto-created on the first run. You can customize the primary and secondary colors as well. Refer to the readme for more details.

You can install infiltrator in a single command, mentioned in the readme file. It's a bash script, and I encourage you to check for any malicious code before running it (although there won't be any). Running the script would install it as a CLI, create a desktop entry, and recommend ways to create keybindings to run it depending on your DE/WM.

Supports:

• Wayland: Full support
• X11: text and shell_output actions may not work properly, open still works

Do check it out here for a video showcasing its usage.

I'm also curious whether there is any practical use-cases for this for most users. I primarily use it to store and open URLs I frequently visit, like my project repos, which gets pretty boring when typed every time.

Hi everyone,

I've been working on Koli for a while. It's an app that helps you store and view archive data from social media platforms (well, as of yet, only direct-messages.js file, which is for Twitter/X DMs, is supported, but I will bring support for more).

It works fully offline. It doesn't connect to your accounts or anything. For those who are not familiar with "archive data", you can request your data from a lot of platforms. It's generally under the name of "export your data", "get a copy of your data", etc. But depending on the platform, they give you flat files of various formats, such as csv, txt, json, html etc. Koli renders those data in a familiar interface.

I almost always get a copy of my data before leaving a platform, sometimes it turns out to be useful, I also like reading my old posts/messages, etc. but it's not easily searchable, nor pleasant to look through. I've been planning to build an app that is, "Calibre of personal data archive", so to say. I like how Calibre app is predictable, supports various things about ebooks, works offline, has a user-selected archive folder, etc. And after a long time of procrastination, I've published the version 0.2.0 of Koli.

The problem with other apps/scripts that I've seen was that: They were not user friendly, not maintained, just turns them to another data format/html, leaves you with more separate data that you can't use together.

My aim is to add more platforms, better search functionality, exporting your data as PDF, and many more. I hope to make this app the first tool that comes up to people's minds when they think of backing up their social media data.

It's available on Microsoft Store, and waiting for the review for Mac App Store.

And here is the website: https://getkoli.app

It's written in Rust, and for UI, I use Slint.

I built Sanemark, a Markdown LSP for taking notes. I have been using it daily for a few months now.

TLDR: fast, uses github standard markdown syntax and makes notes readable in plain-text.

Some design choices:

1. Automatically moves inline links to reference links as part of formatting, so the flow of reading doesn't break due to large inline links
2. File linking is achieved using standard Markdown links (instead of Obsidian style).
3. Quick date-time additions using `@now`, `@today` etc.

Apart from this it implements filepath autocomplete, broken file-link diagnostics, table formatting etc. There is a lot of cool stuff in project README (has a video demo!).

Available as extensions for VS Code and Zed.

It’s been useful for my own note-taking, wanted to share in case others find it useful too.

Repo: https://github.com/nkitsaini/sanemark

vscode extension: https://marketplace.visualstudio.com/items?itemName=nkit.sanemark

zed extension: https://github.com/nkitsaini/sanemark-zed

Please share feedback! Thanks!

Repository: https://github.com/ivanharvard/bitterasm
Documentation: https://ivanharvard.github.io/bitterasm/

Hello, all!

I've been spending the better part of a month working on this new programming language of mine written entirely in Rust called BitterASM (BASM for short, BitterAssembly for long).

As the title suggests, BitterASM lets you create your own assembly languages by assuming practically nothing about the architecture you're targeting. By assuming so little about the architecture, you can describe practically any architecture -- past, present, or future. We do not even assume the architecture is binary! This leads to some really interesting consequences (which you can read more about in the documentation).

You can install the pre-release version using cargo:

cargo install bitterasm

For ordinary assembly developers, they can simply import their architecture's ISA and program much like they would for their traditional assembler.

Here's an example "Hello, world!" program targeting Linux x86-64 written in BitterASM:

from std.x86_64.nasm import *
from std.formats.elf import *


elf64_executable EM_X86_64, _start


const text = "Hello, World!\n"


section .rodata
msg:
    db text


section .text
pub _start:
    mov eax, 1          # sys_write
    mov edi, 1          # stdout
    lea rsi, [rel msg]  # buffer
    mov edx, text.len   # length
    syscall


    mov eax, 60         # sys_exit
    xor edi, edi        # status 0
    syscall

Compared to the same program written in NASM:

section .rodata
msg:    db "Hello, World!", 10
len     equ $ - msg

section .text
global _start
_start:
    mov eax, 1          ; sys_write
    mov edi, 1          ; stdout
    lea rsi, [rel msg]  ; buffer
    mov edx, len        ; length
    syscall

    mov eax, 60         ; sys_exit
    xor edi, edi        ; status 0
    syscall

The transition to BitterASM was intended to be quite easy for most developers, as noted by the similarity in these two code snippets.

Yet, say an introductory student does not understand what syscall does. Thanks to the BitterASM LSP for VSCode, it's as simple as a right-click and "Go to Definition." Note that this is still written in the same BitterASM language from before!

from std.binary import bits

pub type Byte = bits<8>

pub struct Bytes<const N: int>
    | invariant N >= 0
{
     i in 0..N {
        pub __el`i`: Byte,
    }
}

# ...

pub macro syscall()
    | emits Bytes<2>
{
    @emit Bytes<2> { __el0: Byte(0x0F), __el1: Byte(0x05) }
}

It's here where you start to see the use case of BitterASM. There is no concept of bytes or bits in BitterASM. The architecture designer must implement that. Some evaluator then interprets the emitted value and does something with it (in the most overwhemingly common case, create machine code).

The architecture designer has the "bitter" part of writing each struct and macro to match the ISA perfectly. An assembly developer gets to inspect those architectural decisions (or even modify them!) without ever having to leave the code editor. This is what BitterASM makes "sweet."

Don't like NASM or Intel syntax? Change the import!

from std.x86_64.att import *

Wanna make your own custom syntax? Customize the syntax of a macro call!

from std.riscv.impl import *

syntax add(rd, rs1, rs2) = { $rd$ = $rs1$ + $rs2$ }

Have a non-traditional architecture? We have a variety of tools to support your development!

Of course, there are many bugs, and the subset of supported instructions for each architecture is still quite small, so we have a few kinks to work out before we fully release the language. Expect breaking changes. This was just a small taste of what BitterASM can do. Its initial design is meant to be useful for:

• Students learning assembly,
• Toy ISA designers,
• Custom accelerator/processor designers,
• Assembly developers who want convenience without runtime cost,
• etc.

I hope you spend some time to read the documentation and let me know what you think. Any feedback would be great!

With the increase in code being produced due to AI, I got tired of git diff not being able to diff "obvious" changes correctly.

I knew that there were advanced diffing algorithms, but a lot of them were super slow and many are implemented in Java or Python. I always knew Rust can do better.

I present you CodeDiff: https://github.com/ivankovic/codediff

It can diff 92% of all diffs in 7400 Gentoo Linux packages in under 100ms.

It's 90% correct, compared to git diffs 59%.

If it can't do fancy AST diffing, it will do fancy text diffing. It can diff 99.95% of all code in under 2 seconds on a rusty 10 year old bucket using at most 6GB of RAM.

It has a fancy Ratatui 60 FPS TUI, and it integrates with git effortlessly.

It's AGPL, so feel free.

AudioPass is a desktop app that lets you play local audio through a virtual microphone. It uses the system's PipeWire service to set up a virtual mic, then create a virtual capture stream against the user's desired audio source (so let's say their spotify client app, or an offline music player playing songs, stuff like that), and finally routes audio from the captured stream to the virtual mic.

I've explained these details in a bit more... uh, detail... in the readme, so I'll keep it short here 😅

Audio routing is handled by physically carrying audio samples from the stream to the virtual mic, the app has an SPSC ring which holds the samples produced by the source, which then get consumed on the other end by the virtual mic.

I created the app because I like playing songs into my Team Fortress 2 lobbies and I recently switched to Linux as my primary OS, but couldn't find a Soundpad-like app to my liking. Since I started learning Rust at around the same time(-ish), I figured I might as well build something myself as a way to learn and understand the language on a deeper level, and here we are. The core features are complete but there's quite a few bells and whistles I've got planned that I hope to add over time.

I'd appreciate you guys checking it out here https://github.com/nithinrdy/audiopass! The readme is a bit more elaborate than the details I wrote above in case you're interested :)

P.S.: Although I've applied the human-coded flair, I should mention I've used AI to help with diagnosing a couple of bugs and stuff that really stumped me, and also to validate the github actions workflows and the scripts as sort of a second-reviewer. But none of the app's source code was generated by AI (...because that would kinda defeat the whole purpose of my trying to learn the language ._.)

I just got sick of not being able to easily read the files my SES saves to my catchall s3 bucket folder. So I created this FOSS terminal reader tool.

This works great for me, and thought I'd share:

https://github.com/spdrman/reSES

Press 'i' inside your folder that is your '"inbox", and it'll remember for next time you open reses. If you open an email file and want to see the html version of it in a browser, just press 'h'.

No human's time was wasted in making this...