Hello, Rustaceans!

I released 0.4.2 yesterday and wanted to introduce people who might be interested in the project, talk about the changes in the release, where I plan on taking the project in the future and a quick rant on the AI policy the project will have going forward.

First of all, I want to thank @ Seuros, TheAiteb and tom-lubenow for their contributions in the past few weeks and months. This is my first ever open source project and I'm glad that people didn't only find a use case for it but also actively helped improve it!

What has changed in v0.4.2:

• More control over the palette. Choose which plugin types it offers, open and render it from your app, and receive the selection to handle yourself. Useful when choosing a plugin should focus an existing pane or follow your own application logic.
• Stable tab IDs. Each workspace tab now has a TabId, with helpers to check which tabs remain open. This makes tracking state such as notifications per tab easier.
• The core no longer pulls in Crossterm. It now builds for Wasm targets, including wasm32-wasip2. Thanks again to Tom for this.
• Fixed a bug causing keyboard actions to fire twice on Windows (already fixed in 0.4.1 but I didn't make a post about it)

AI Policy

It's undeniable that LLMs today are not the ones from last year, they are more than capable of producing quality code, finding bugs and improving performance. Hypertile DOES have AI generated code in it, even though it started out as my little learning project. That being said, as of yesterday, the project will adopt ripgreps AI policy as well as an AGENT.md linking to .rules, this one being adopted from Zed. While I do not have any plans on trying to create an artisan or sophisticated guide for LLMs, I am not delusional enough to believe that people contributing won't use LLMs to generate their code. I have also adopted policies from the Linux Kernel regarding the use of coding assistants of any kind.

TLDR: You can use AI for code, you must disclose what you used, you may not communicate in PRs, Issues or anywhere using LLMs. You own the code you publish regarding of how it was created.

FAQ:

I did not think I'd actually need a FAQ question but one thing that constantly keeps popping up is:

Why not just use tmux or ZelliJ?

They are not mutually exclusive! The point of Hypertile is allowing people to write their CLI tools in a way that allows them to be modified at runtime instead of the look and feel being baked in at compile time as most TUIs do. You can use your ratatui-hypertile app in ZelliJ just fine.

As always, any and all feedback is welcome! :)

Repository - Core crate - Extras crate

Hi everyone! I asked this earlier in the week, but I don't think I explained my question very well (sorry for the translation; I'm a Spanish speaker).

I want to learn how to develop graphical user interfaces (GUIs).

I'm generally new to programming, but I really like Rust; I don't know any other languages—just Rust.

I want to build a project for the company I work for. We mostly use Excel for our data; our "database" (an Excel file) is 500k rows by 25 columns (though there are several files covering different areas, so the total exceeds a million data points).

I want to automate this. That million data points is spread across years; the most critical process involves each of us reviewing 100 items in 30/40 minutes—classifying, validating, sorting, etc.

I need to create something like dashboards featuring:

charts and tables that are sortable and filterable.

These two components are absolutely critical.

For the rest, I'm thinking of a data grid (something like Excel, but not a full spreadsheet—just small tables with editable cells).

We need this because our values ​​aren't always 100% accurate; there's a lot of human error involved in our work.

For example: Our system registers a client who has a discount percentage, but that wasn't included in the initial registration request. So, the discount doesn't apply the first time. Later, we receive the correction, and the discount applies to the second sale—at which point we also correct the first sale.

This happens across all areas, so I need something editable. Given our limited review time, I need the interface to be fast and intuitive.

I don't need mobile support—though it would be a nice-to-have, it's not essential. I need a recommendation focused 100% on desktop.

It also needs to properly support Windows, Mac, and Linux.

Which GUI crate would you choose? (I know it's difficult for me, but I want to learn a lot)

There are situations when decisions must be made based on many variables, and in some points in evalution process, additional costly operations must be performed in order to decide. These decisions are difficult to implement in the form of a single logical expression, and even if it is possible, it is unreadable and hard to modify.

Usually the best pattern for this is to create a separate function which implements the decision, where we can use early returns: the trivial and easy cases that can be decided based on a simple condition (especially exceptions) are evaluated first, we return with the result as soon as possible, so as we're going foward, we reduce the complexity of the remaining cases, and the last case is often a simple condition.

Sometimes a separate function is not an option, because too many parameters would have to be passed (and returned, but Rust have tuples for it), or it simply just does not feel right to split a single decision into two functions, I think, the single-responsibility principle (SRP) must work this way, too. It's even more true for not too complex but nested cases (certain part of the condition is consist of more sub-conditions).

In C and C++, I usually implement this pattern by creating a do..while(false) loop, from which I break at several points, skipping the rest of the evalutation. I store the result in a variable declared just before the block, usually initialized to the default value.

It may just be my fault that I haven't studied the Rust textbook enough, but I've only found the functionally equivalent syntax for this today, and I am very happy with it, with its flexibility and elegance: labeled block.

Let's see an example!

The decision is about whether close (do_close_old flag) the old time window and/or replace with a new one (do_replace_window flag), also log some info about the decision (replace_reason enum), see example (close to actual code):

let (do_close_old, do_replace_window, replace_reason) = 'switch: {

    if just_created {
        break 'switch (false, false, Reason::Create);
    }

    if window.is_retired {
        break 'switch (false, true, Reason::Replace);
    }

    if window.is_expired(timestamp, lifetime_duration) {
        break 'switch (true, true, Reason::Timeout);
    }

    // complicated condition, fake
    let compli = if (x && y) | (a && !b);
    let cation = if z > w {
      countries.find("USA") && languages.find("English")
    } else {
      false
    };
    if compli && cation {
        break 'switch (true, true, Reason::ComplicationHappened);
    }

    (false, false, Reason::None)
};

(Please, don't review my code, I know, I know, somehow the result tuple should be replaced with some named thing.)

I think, it's pretty well readable, even if you haven't met with labeled blocks before. Just as me, until today.

AI disclaimer:

• helped in translation (my English is not suitable for publications)
• the pattern was also suggested by AI, I often ask it to refactor short code snippets

Hi everyone,

I'm Abinash. For the past few weeks, I have been working on building a neural network in Rust to test the idea of using Rust in model development and research.

Rust is being extensively used in LLM infrastructure and is growing in the inference space as we get official libraries to run CUDA kernels from Rust binaries.

But if you see the model design, research or development space, Rust is non-existent.

So I thought I'd give it a try. I tried to build a fairly easy neural network to solve the MNIST handwritten digit identification problem.

I know it's not a huge milestone. But I tried to give it a try to test my idea how easy it is to develop neural networks in Rust.

The neural network I'm developing has 2 hidden layers with 512 and 128 neurons, respectively. The goal is to achieve 95% accuracy on my local CPU-only system.

I got the input system right; it can now take training and testing datasets and prepare the matrices for the training and testing stages.

After that, I plan to start developing a real transformer-based LLM from scratch in Rust.

I'm not sure how it will play out, but I will give it a try.

I'd love to have your thoughts on it. If you're a senior ML engineer or MTS at a frontier lab, I'd love to have your thoughts on it.

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

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

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

Hey guys!

I've been building a GPU compute platform on pure stable-rust to let you write compute kernels directly in standard rust, Built entirely on Vulkan 1.3 (Compute) for the host api runtime & MLIR/LLVM for the backend JIT compiler.

It can make you write iters-enums-generics-etc.. in your function, and run it across GPU silicon, because the syntax is literally rust, It can execute on native CPU.

Here is a simple example:

```rust use enki::*; use glam::Vec2;

const COUNT: usize = 5;

// Declare the compute kernel with #[nam]

[nam]

fn scale_vectors(_space: &Space, input: &Vec2, output: &mut Vec2, factor: f32) { *output = *input * factor; }

fn main() { // Initialize the headless GPU runtime let enki = Enki::init();

// Allocate physical data directly in GPU VRAM
let in_gpu = gpu_vec![
    Vec2::new(1.0, 2.0),
    Vec2::new(3.0, 4.0),
    Vec2::new(5.0, 6.0),
    Vec2::new(7.0, 8.0),
    Vec2::new(9.0, 10.0),
];
let mut out_gpu = gpu_vec![Vec2::ZERO; COUNT];

let factor = 2.5f32;

// Record and dispatch directly to GPU silicon
enki.flow(|_| {
    scale_vectors.run(
        &Space::gpu_x(COUNT),
        &in_gpu,
        &mut out_gpu,
        GpuParam::new(factor),
    );
});

// Dual Execution: Run the exact same function on CPU native rust
let in_cpu = vec![
    Vec2::new(1.0, 2.0),
    Vec2::new(3.0, 4.0),
    Vec2::new(5.0, 6.0),
    Vec2::new(7.0, 8.0),
    Vec2::new(9.0, 10.0),
];
let mut out_cpu = vec![Vec2::ZERO; COUNT];

for i in 0..COUNT {
    scale_vectors(&Space::cpu_x(i, COUNT), &in_cpu[i], &mut out_cpu[i], factor);
}

// Verify bit-for-bit equivalence
assert_eq!(&out_cpu[..], &out_gpu.to_vec()[..]);
println!("\nGPU Results: {:?}", out_gpu);
println!("\nCPU Results: {:?}", out_cpu);
println!("\nCPU and GPU outputs match.");

} ```

Result:

``text enki_matmul on  master [✘!+] is 📦 v0.1.0 via 🦀 v1.98.1 ❯ cargo run Compiling enki_matmul v0.1.0 (/home/mohiman/Projects/enki_demo_pack/enki_matmul) Finisheddevprofile [optimized + debuginfo] target(s) in 1.86s Runningtarget/debug/enki_matmul`

GPU Results: [Vec2(2.5, 5.0), Vec2(7.5, 10.0), Vec2(12.5, 15.0), Vec2(17.5, 20.0), Vec2(22.5, 25.0)]

CPU Results: [Vec2(2.5, 5.0), Vec2(7.5, 10.0), Vec2(12.5, 15.0), Vec2(17.5, 20.0), Vec2(22.5, 25.0)]

CPU and GPU outputs match.

enki_matmul on  master [✘!+] is 📦 v0.1.0 via 🦀 v1.98.1 took 2s
❯ ```

I've verified it on Linux (Docker Container Testing) & Windows (Wine) & colab T4, and my intel UHD laptop, every thing was great, i'd really love your help testing across more diverse hardware (AMD, Nvidia, Intel)

You can test SDF showcase in 3 commands:

bash git clone https://github.com/enkiruntime/enki_sdf.git cd enki_sdf cargo run --release

(pressing space will toggle execution from GPU (Enki) to CPU (rust-rayon))

• GitHub Repo: https://github.com/enkiruntime/enki

Enki is currently in Public Alpha (v0.2.x) release, I would really appreciate any feedback, architectural thoughts, or bug reports.

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

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

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

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

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

ArcColdString

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

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

Usage

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

use cold_string::ArcColdString;

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

Memory Comparisons

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

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

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

Reference Counting Performance

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

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

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

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

I'm working on a Rust SDK that has a small check() method for testing a proxy connection, and I'm not sure I'm using Result in the least surprising way here.

If the proxy replies with 407 Proxy Authentication Required, I currently return Ok(Check), not Err.

My reasoning is basically: the check itself worked) I connected to the proxy and got a real response back. For this method, the status/reason/headers are useful information.

Err is only for cases where I couldn't get a usable response at all - timeout, DNS failure, connection failure, malformed response, etc.

Roughly:

match proxy.check(connect)? {
    check if check.status == 200 => {
        // accepted
    }
    check if check.status == 407 => {
        // proxy replied, auth rejected
    }
    check => {
        // some other resp
    }
}

The part that feels a bit weird is this:

let check = proxy.check(connect)?;

That kind of reads like "the proxy is fine", while what it really means is only "the proxy gave a usable response".

Would you expect 407 to be an Err here, or does treating a protocol-level refusal as a successful diagnostic result make sense? 🙊