Tea and Bits

Sliced by Go's Slices

Thu, 26 Feb 2026 16:00:00 +0000

Today, I was sliced by Go’s slices. Actually, by Go’s variadics. Question: what does this snippet print?

func main() {
	nums := []int{1, 2, 3}
	PrintSquares(nums...) // variadic expansion
	fmt.Printf("2 %v\n", nums)
}

func PrintSquares(nums ...int) {
	for i, n := range nums {
		nums[i] = n * n
	}
	fmt.Printf("1 %v\n", nums)
}

Answer (Playground):

1 [1 4 9]
2 [1 4 9]

🫠

Meaning, in Go, when you use a slice for variadic expansion (s...), and you use a variadic parameter to capture said slice (paramSlice ...int), they are the same¹ slice, and mutating one will mutate the other.

&&&&&&&&&&&&&&str

Fri, 09 Jan 2026 14:00:00 +0000

While adding a failing test to the Rust compiler, I stumbled upon a peculiar code generation test:

pub fn thirteen_ref(input: &&&&&&&&&&&&&str) -> String {
 // CHECK-NOT: {{(call|invoke)}}{{.*}}@{{.*}}core{{.*}}fmt{{.*}}
 input.to_string()
}

// This is a known performance cliff because of the macro-generated
// specialized impl. If this test suddenly starts failing,
// consider removing the `to_string_str!` macro in `alloc/str/string.rs`.
//
pub fn fourteen_ref(input: &&&&&&&&&&&&&&str) -> String {
 // CHECK: {{(call|invoke)}}{{.*}}@{{.*}}core{{.*}}fmt{{.*}}
 input.to_string()
}

In case you are wondering where are the tests here: the CHECK and CHECK-NOT comments are actually the test assertions, which are tested using LLVM’s FileCheck framework.

Why is calling my asm function from Rust slower than calling it from C?

Sat, 27 Dec 2025 10:00:00 +0000

This is a follow-up to making the rav1d video decoder 1% faster, where we compared profiler snapshots of rav1d (the Rust implementation) and dav1d (the C baseline) to find specific functions that were slower in the Rust implementation¹.

Today, we are going to pay off a small debt from that post: since dav1d and rav1d share the same hand-written assembly functions, we used them as anchors to navigate the different implementations - they, at least, should match exactly! And they did. Well, almost all of them did.

Making the rav1d Video Decoder 1% Faster

Thu, 22 May 2025 10:00:00 +0000

*on macOS with an M3 chip
*slightly more than 1%, on a specific benchmark, without any new unsafe code

A while ago, memorysafety.org announced a contest for improving performance of rav1d, a Rust port of the dav1d AV1 decoder.

As this literally has my name written on it, I thought it would be fun to give it a try (even though I probably can’t participate in the contest).

This is a write-up about two small performance improvements I found (1st PR, 2nd PR) and how I found them (you can also jump to the summary in the end).

BTrees, Inverted Indices, and a Model for Full Text Search

Thu, 10 Apr 2025 00:00:00 +0000

Whenever I get into a new technology, I try to build myself a mental model of how it works. Let’s do that for full text search engines, by writing a minimal implementation in Rust

Debugging a Vision Transformer Compilation Issue

Wed, 22 Jan 2025 00:00:00 +0000

After updating the TensorRT version we use to compile ML models at work, I got a failure in a test: the test feeds a video to a model expecting a specific classification, but the model produced complete garbage. This led me on an unusual debugging quest, dissecting a Vision Transformer layer by layer.

Making Python 100x faster with less than 100 lines of Rust

Tue, 28 Mar 2023 00:00:00 +0000

Update: I gave a talk on this topic at P99 CONF 2023 and at PyCon IL 2024 (Hebrew).

A while ago at $work, we had a performance issue with one of our core Python libraries.

This particular library forms the backbone of our 3D processing pipeline. It’s a rather big and complex library which uses NumPy and other scientific Python packages to do a wide range of mathematical and geometrical operations.

Our system also has to work on-prem with limited CPU resources, and while at first it performed well, as the number of concurrent physical users grew we started running into problems and our system struggled to keep up with the load.

A Rust API Inspired by Python, Powered by Serde

Wed, 07 May 2025 12:00:00 +0000

Years ago, I worked on reimplementing some Python code in Rust and needed to adapt Python’s dynamic reflection capabilities (aka __getattr__) to the strict and compiled world of Rust…

Frankenstein’s `init`

Sat, 19 Apr 2025 10:00:00 +0000

The untold story of the craziest __init__ I’ve ever seen.

Put a Pin on That

Tue, 11 Jul 2023 17:00:00 +0000

There are some things you keep learning and forgetting (or perhaps you’ve never learned them in the first place?).

For me, one of those things is Pin/Unpin in Rust.

Every time I read an explanation about pinning, my brain is like 👍, and a few weeks later is like 🤔🤨.

So, I’m writing this as a way to force my brain to retain (pin?) this knowledge. We’ll see how it goes!

Pin is a type of pointer, which can be thought of as a middle ground between &mut T and &T.

State of the Crates 2025

Mon, 09 Dec 2024 00:00:00 +0000

One of the best things about Rust is that there are so many high-quality crates for everything and anything you want.

It can be hard to choose, so I wanted to share some of the crates I used this year at $work and explain why.

You can also jump to the end for the final Cargo.toml.

For context, we’re a small-ish Rust & Python shop handling compute-heavy workloads on-prem. Our system is split into a reasonable number of services that talk to each other mostly over RabbitMQ or HTTP.

My most downvoted StackOverflow answer

Thu, 05 Sep 2024 00:00:00 +0000

Sometimes, I get mad at someone on the internet.

It’s just so easy, isn’t it?

Then, I remember my most downvoted StackOverflow answer, and I become less angry.

I wrote the actual answer many years ago, but the angry-ness is much more recent.

Apparently, I angered someone on a topic that is so controversial that my answer became part of a StackOverflow Meta(!) discussion about how to deal with such terrible answers.

Winning the fight against the Rust compiler (Coherence in Rust, feat. rustc sources)

Wed, 10 May 2023 12:00:00 +0000

An unexpected error

A friend was experimenting with Rust and asked if I could help decipher an error message for them:

PS Z:\Projects\aoc\src\bin> cargo build --bin=2021_day19
 Compiling aoc v0.1.0 (Z:\Projects\aoc)
error[E0210]: type parameter `T` must be covered by another type when it appears before the first local type (`VecN<T, N>`)
 --> src\vec.rs:65:6
 |
65 | impl<T: MulAssign, const N: usize> Mul<VecN<T, N>> for T {
 | ^ type parameter `T` must be covered by another type when it appears before the first local type (`VecN<T, N>`) 
 |
 = note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local, and no uncovered type parameters appear before that first local type
 = note: in this case, 'before' refers to the following order: `impl<..> ForeignTrait<T1, ..., Tn> for T0`, where `T0` is the first and `Tn` is the last

And, I could! I actually updated this error message (in #66253) after helping stabilize RFC 2451 (re-rebalance coherence) in #65879.

But this error is indeed strange.

Isn’t one of the reasons for using traits is to allow others to implement them? Why does Rust reject this particular combination of structs, traits and generics?

How to Build Python Code with Bazel (and Why)

Tue, 09 Sep 2025 06:00:00 +0000

How can you build Python code with Bazel? Why would you even want to do that?

This is the topic of a lightning talk I gave at PyCon IL this year. Below are the slides and a transcript, starting with why this is a problem that you might have. You can also jump right into the part about how Bazel can solve that problem, or check the GitHub repo.

Zig is not F'ing memory safe

Sat, 10 May 2025 08:00:00 +0000

It’s not. I’m not saying that’s inherently bad. It’s just what it is. Consider the following code:

var gpa = std.heap.GeneralPurposeAllocator(.{}){};
const allocator = gpa.allocator();

var list = try std.ArrayList(u8).initCapacity(allocator, 4);
try list.appendSlice("Hell");

const c = &list.items[0];

try list.append('o');
try list.append(c.*);

It compiles just fine but triggers a segfault due to a Use-After-Free bug in the last line:

$ zig run main.zig
Segmentation fault at address 0x104b00000
aborting due to recursive panic
zsh: abort zig run main.zig

If you have a use case where you don’t care about that - you do you!

Mon, 01 Jan 0001 00:00:00 +0000

Hi!

This is my blog. I write about software, performance, Rust, Python and the like. Usual disclaimer: views are my own.

Everything here is written entirely by me: LLMs are cool and all, but writing is like going to the gym, and sharing an LLM’s writing on the internet without disclosure is rude.