DEV Community: Luis Enriquez Aracena Cabrera

What are bloom filters and how i use them

Luis Enriquez Aracena Cabrera — Fri, 13 Jun 2025 09:46:04 +0000

What are bloom filters and how i use them

A few days ago, a friend of mine — Zangarmash — told me about Bloom filters.

Up until that moment, I had no idea they even existed, but as he explained how they work, I started to grasp their potential. And to me, that could only mean one thing: sooner or later, I’d have to use them.

I’m not usually the type to work on side projects, but lately, I’ve been revisiting my “go-to project” — the one I build every time I study a new programming language and want to go beyond basic tutorials to really challenge myself whit basic stuff.

This time, the language is Go, and during development, Bloom filters came to mind again. I had finally found the perfect use case: using one to check whether a file is possibly present in the file system before attempting access, avoiding unnecessary disk reads.

What Is a Bloom Filter?

A Bloom filter is a data structure that allows you to determine whether an element is definitely not present or possibly present in a set, using a probabilistic lookup mechanism.

This distinction is crucial: a Bloom filter can produce false positives (i.e., it may say an element is present when it’s actually not), but it never returns false negatives.

In other words: if the filter says “not present,” then it’s definitely not there; if it says “maybe present,” it could be wrong.

Understanding this behavior is essential, because there are situations where using a Bloom filter may be pointless — or even counterproductive — compared to other solutions.

Technically, a Bloom filter consists of:

n, the size of the bit array representing the filter;
k, the number of distinct hash functions used for each inserted element.

When we add a value to the filter, we apply the k hash functions, which give us k positions in the bit array of length n. At each of these positions, we set the bit to 1.

An Intuitive Example: Mailboxes

Imagine a row of mailboxes numbered from 0 to n.

Every time you want to “register” a name (say, “Alice”), you use k different keys (the hash functions) that tell you which mailboxes to open. For each indicated mailbox, you drop in a slip of paper.

When you want to check if “Bob” has already been registered, you repeat the process with the same keys. If all the mailboxes you’re supposed to check already contain slips, then Bob is possibly already registered.

But if even one of those mailboxes is empty, you can say with certainty that Bob has never been registered.

How Does It Work?

For each element we want to add to a Bloom filter, we use k deterministic hash functions. This is important: given the same input, the hash result must always be the same. That’s essential to determine whether a value is “possibly present” or not.

⚠️ If we used cryptographic hash functions (like SHA-256), we could end up with different results for the same input — due to salting or other non-deterministic mechanisms — which would break the entire logic of the filter.

The Two Core Operations

A Bloom filter supports only two operations:

Add: adds an element by applying the k hash functions and setting the resulting positions to 1.

Check: checks if an element is possibly present by reapplying the k hashes and verifying whether all corresponding positions are set to 1.

Removing an element from a Bloom filter is not possible, because we can’t know whether the bit positions we want to clear are also used by other elements.

For this reason, the only safe way to “delete” is to rebuild the filter from scratch — or better yet, avoid deletions altogether.

Adding an Element

Let’s say we want to add the word "Hi" to the filter. We apply the k hash functions to this string, getting values like 42, 87, 109, and so on.

These values are then normalized to fit within the filter size n (for example using value % n), and for each resulting position, we set the corresponding bit to 1.

Checking an element

If even one of the positions is 0, we can be certain that the element is not present in the filter.

If all the bits are 1, then the element might be present — or it might be a false positive caused by other elements previously added.

Why It’s Called “Probabilistic”

This is where the probabilistic nature of a Bloom filter becomes clear. We can’t be 100% sure an element is present, because different inputs might produce the same hash results (collisions).

But we can be completely sure that an element is not present if even one of its corresponding bits is 0.

Optimizing the Number of Hash Functions (k)

An obvious way to reduce false positives is to increase the number of hash functions k. But be careful: doing this excessively can have the opposite effect, saturating the filter and degrading performance.

There’s actually a sweet spot that balances:
-m: the number of elements we expect to insert;
-n: the size of the filter’s bit array;
-k: the number of hash functions to use.

To find the optimal number of hash functions k, we can use the formula:

k = (n / m) * ln(2)

Suppose we want to create a filter with:

n = 10,000 total bits,
m = 1,000 elements to insert.

We compute:

k = (10,000 / 1,000) * 0.693 = 10 * 0.693 = 6.93

So the optimal number of hash functions to use is around 7.

Using this value of k helps balance the filter’s accuracy and performance, minimizing the probability of false positives.

How I Implemented a Bloom Filter in My Go Project

In my "go-to project", I decided to use a Bloom filter to optimize checks for the presence of files in the file system.

The logic is simple:

If the file is not present in the filter, I generate and save it.
If the filter says the file might be present, I check if the file actually exists. If it does, I do nothing; if it doesn’t, I proceed to generate it.

This use case, though simple, is a perfect fit for a Bloom filter — it helps reduce unnecessary disk accesses and saves precious time.

My Current Implementation

So far, I’ve built a basic version of the filter with fixed values for the size n and the number of hash functions k:

n = 32 (a very small filter, 32 bits);
k = 3 hash.

To generate the k hash functions, I used the 64-bit hash from cespare/xxhash, a fast and reliable Go library.

From the 64-bit hash, I derived two values:

hash: the result of xxhash64 applied to the input;
h1: the lower 32 bits of hash (hash & 0xFFFFFFFF);
h2: the upper 32 bits ((hash >> 32) & 0xFFFFFFFF). ### Double Hashing to Get Distinct Hashes To generate the k distinct hashes (i.e., filter positions), I use the double hashing technique, which is quite common in Bloom filter implementations:

for i := range b.k {
    generated := h1 + h2*i
    hashes[i]  = uint32(generated % 32)
}

How I Add and Check Elements

In my filter, I use a single uint32 as a bit array (32 bits total).

To add an element:

func (b *bloomFilter) Add(value []byte) {
    hashes := b.getHashes(value)
    for _, hash := range hashes {
        b.Filter |= 1 << hash
    }
}

To check if an element is present:

func (b *bloomFilter) Contains(value []byte) bool {
    hashes := b.getHashes(value)
    for _, hash := range hashes {
        if (b.Filter & (1 << hash)) == 0 {
            return false
        }
    }
    return true
}

Possible Improvements

This is a simple version that works well for a limited number of elements.

In the future, I’d like to:

Dynamically calculate the filter size n and the number of hash functions k based on the number of files, to reduce false positives;
Replace the single uint32 with a larger bit array to handle more data;
Consider using more advanced or optimized hashing functions.

In conclusion, Bloom filters are powerful and fascinating tools, especially when you want to optimize presence checks without consuming too much memory or computational resources. Of course, they’re not the perfect solution for every use case, but in specific contexts — like my project — they can be incredibly effective.

Had you heard of them before? Have you ever used or implemented one in your own work?

If you have tips, questions, or just want to chat about the topic, feel free to reach out — you can email me or contact me on social media.
I always enjoy exchanging ideas!

Useful links

Bloom filters - Eli Bendersky's website

Why I Can’t Live Without Docker Anymore

Luis Enriquez Aracena Cabrera — Tue, 10 Jun 2025 08:18:39 +0000

My journey with Docker began in 2017 while working on a project for Brunello Cucinelli. At the time, we had to use Docker to replicate the production environment, and for me, it was one of my first encounters with this technology.

As often happens with new and unfamiliar tools, it was hate at first sight. I couldn’t understand the difference between a Dockerfile and a docker-compose.yml, I had no clue what the instructions inside those files meant, and to top it off, I was working on Windows — in the pre-WSL era.

Docker on Windows: A Bumpy Ride

Anyone who has tried Docker on Windows (not WSL or Windows Server) knows that performance isn’t great. This is because Docker isn’t a traditional virtual machine; containers run on top of the host OS, and on Windows, this is much less efficient than on Linux.

The introduction of WSL (Windows Subsystem for Linux) drastically improved the experience, allowing a Linux environment to run inside Windows and making Docker more usable. However, back in 2017, WSL wasn’t stable or widely adopted, and Docker remained a complex and frustrating tool.

At that time, only two members of my team had a basic understanding of Docker, which made it hard to figure out what to do when docker-compose up failed. To make things worse, we used Docker exclusively via Docker Desktop’s GUI, which hid all the real CLI commands being executed under the hood.

Switching to Linux: Game Changer

In 2022, I changed companies — and operating systems. I moved to Ubuntu, a well-known Linux distribution that allows Docker to run natively without Docker Desktop.

This shift changed everything. For the first time, I could clearly see what was happening behind the scenes. I could read and understand the configuration files, debug real errors, and run CLI commands with full control.

Docker was no longer a black box, but a powerful tool in my hands.

Sure, I could have started learning it earlier — Windows didn’t prevent me from studying the tech — but the reality is that it made everything harder and more frustrating.

Can’t Work Without It

Today, I can’t imagine working without Docker. I don’t want to install PHP (in all its versions), MySQL, or any other service directly on my machine. I want clean, isolated, reproducible environments that don’t interfere with my host OS.

I honestly don’t know how we managed to work on multiple projects with different dependencies in the past. Changing the $PATH, switching extensions, tweaking ports and configs… I still remember the frustration and anxiety of breaking something important.

Now, switching between projects and their dependencies is just a matter of two or three commands — often mapped to aliases — and each environment works exactly as needed.

Fast Start with a Docker Template

Another huge benefit is being able to start a brand-new project in seconds — even with a completely different stack. Want to test a new version of MariaDB or PHP? No problem.

To make this even easier, I created a public GitHub repository with some base Docker configurations I frequently use:

🔗 https://github.com/IceWizard98/basic_docker

The goal is to grow this repository over time, adding more technologies, with the help of contributors who know certain stacks better than I do. The idea is to have a solid, ready-to-use foundation for any new project — without having to copy and paste configs from previous repos.

If you’d like to contribute, you’re more than welcome! I’d love to see your PRs. 🙌

If you’d like to share your own Docker experience, or just chat about dev stuff, you can reach me here.

And if you’re using a cool Docker template, I’d love to see it!
You can find my original article here luise.ac

From TikTok to Text: Starting My Journey into Written Content

Luis Enriquez Aracena Cabrera — Sun, 08 Jun 2025 11:18:56 +0000

For the past few months, I’ve been creating short video content on TikTok where I share my (still limited) experience as a developer with those who are just starting out.
The goal has always been simple: to help junior devs — or future devs — feel a little less alone when facing the complexities of this field.

I’ve never considered myself a “guru” or anything like that. I just try to explain things the way I would’ve liked someone to explain them to me — with clarity, honesty, and maybe a bit of humor.

Discovering Obsidian and Simon Späti

At some point during this journey, I stumbled across @ssp.sh — Simon's content really struck a chord with me.
One of the biggest takeaways from following his work was discovering Obsidian, a powerful (and local-first!) tool for note-taking and knowledge management.

I started using Obsidian to keep track of what I was learning from tutorials, blog posts, videos, Twitter threads… basically anything useful. Over time, my note vault became not just a study tool but a kind of personal knowledge base.

This shift made me rethink how I learn and how I share what I learn.

The Push Toward Self-Hosting

Then I read this article by Simon:
👉 “Why Self-Host? For Self-Independence.”

It really resonated with me. The idea of self-hosting — not just for control or privacy, but for long-term sustainability and independence — made me reconsider the way I approach both content and tools.

It made me realize that while video is a great medium, text has a different kind of permanence. A post, an article, or even a note can be referenced, linked, updated — and self-hosted, if needed.

That’s when I decided to give written content a real try.

What About My Site and GitHub?

I already have a personal website (still pretty minimal), where I’ve just added a short bio about myself and what I do. Nothing fancy — just a placeholder for now, but I hope to expand it as I publish more.

As for GitHub, I’ve created and used several small tools and scripts for personal use, but I’ve never really made them public.
Why? Mostly out of fear of judgment — the classic imposter syndrome that I think many of us face in this field.
“Is this code good enough? Will someone point out how bad it is? Should I even share it?”
These questions often stopped me before I even tried.

But I’m slowly learning that done is better than perfect — and that sharing, even imperfectly, is still valuable.

My First Post on dev.to

To get started, I published my first-ever post here on dev.to.
It’s nothing groundbreaking — a basic, standalone piece — but it represents a small personal milestone.
Not just “writing something,” but stepping into a new mindset: one that values depth over speed, permanence over trends.

What’s Next?

I’m not sure what this new phase will bring. I’ll still make videos on TikTok — but I’m also going to write more often. Short articles, notes, maybe tutorials, maybe just thoughts.

If you’re a junior developer, a content creator, or someone who’s just trying to build their own path — I hope we’ll learn something together along the way.

Thanks for reading. And if you have any advice, feedback, or just want to say hi — feel free to drop a comment!

Useful Links

Obsidian.md
Simon’s Blog - ssp.sh
Why Self-Host? For Self-Independence.
My TikTok Profile (if you want to see the videos I’ve been making)
My GitHub (it’s a bit quiet for now, but stay tuned!)

From TikTok to Text: Starting My Journey into Written Content

Luis Enriquez Aracena Cabrera — Sun, 08 Jun 2025 11:18:56 +0000

Discovering Obsidian and Simon Späti

This shift made me rethink how I learn and how I share what I learn.

The Push Toward Self-Hosting

Then I read this article by Simon:
👉 “Why Self-Host? For Self-Independence.”

It made me realize that while video is a great medium, text has a different kind of permanence. A post, an article, or even a note can be referenced, linked, updated — and self-hosted, if needed.

That’s when I decided to give written content a real try.

What About My Site and GitHub?

But I’m slowly learning that done is better than perfect — and that sharing, even imperfectly, is still valuable.

My First Post on dev.to

What’s Next?

I’m not sure what this new phase will bring. I’ll still make videos on TikTok — but I’m also going to write more often. Short articles, notes, maybe tutorials, maybe just thoughts.

If you’re a junior developer, a content creator, or someone who’s just trying to build their own path — I hope we’ll learn something together along the way.

Thanks for reading. And if you have any advice, feedback, or just want to say hi — feel free to drop a comment!

Useful Links

Obsidian.md
Simon’s Blog - ssp.sh
Why Self-Host? For Self-Independence.
My TikTok Profile (if you want to see the videos I’ve been making)
My GitHub (it’s a bit quiet for now, but stay tuned!)
My website

Go and Error Handling: A Final (Almost) Word

Luis Enriquez Aracena Cabrera — Fri, 06 Jun 2025 13:45:32 +0000

The Go team recently published what feels like a final update on a long-debated topic: error handling.

After years of proposals, experiments, and community discussions, the conclusion is simple and clear:

The current approach is considered good enough, and there’s no plan to change it.

The post explains that many alternative designs were explored, some even prototyped, but none of them made a compelling enough case to justify a language change — though the team remains open to community input.

The most promising proposal (IMO)

Out of all the options discussed over the years, the one I find most aligned with Go’s philosophy is a compact ? syntax for handling errors.

Example:

res, err := doSomething() ?

Here’s the idea:

If the function returns an error, it gets automatically propagated;
If the current function doesn’t return an error, a panic(err) is triggered — just like developers often write manually.

You could even manipulate the error inline before returning:

res, err := doSomething() ? fmt.Errorf("problem with %q", param)

This avoids repetitive if blocks while still keeping the error flow explicit and customizable.

Compared to the classic approach

The current Go idiom:

val, err := strconv.Atoi(input)
if err != nil {
    return err
}

With ?, that becomes:

val, err := strconv.Atoi(input) ?

Behavior stays the same.
But it’s cleaner, less noisy, and easier to follow, especially when the same pattern repeats across multiple lines.

More complex example:

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return fmt.Errorf("invalid a: %w", err)
    }

    y, err := strconv.Atoi(b)
    if err != nil {
        return fmt.Errorf("invalid b: %w", err)
    }

    fmt.Println("result:", x + y)
}

Could become:

x, err := strconv.Atoi(a) ? return fmt.Errorf("invalid a: %w", err)
y, err := strconv.Atoi(b) ? return fmt.Errorf("invalid b: %w", err)
fmt.Println("result:", x + y)

An alternative — not a replacement

Let’s be clear:
This kind of syntax isn’t meant to replace the existing error handling in Go. It’s meant to complement it.

The familiar if err != nil remains 100% valid and is still necessary when you need custom error logic.

The ? operator would be just an alternative for the most common patterns — a shorthand, not a shift in philosophy.

And since Go’s compiler already understands function signatures, propagating errors where appropriate would be safe and predictable.
Default return values (nil, 0, "", etc.) would be inferred, just as they are today.

Why I (partially) disagree with the Go team

Go values explicitness, simplicity, and predictability. The verbosity of its error handling reflects those values. That’s totally fair.

But still — in the vast majority of cases, error handling in Go is formulaic: check error, return or panic.

Recognizing that, and providing a built-in syntax for it, wouldn’t hurt Go’s clarity. In fact, Go already supports concise syntax when it improves readability, like the := short declaration.

The ? operator would just follow that same principle:
optional, minimal, idiomatic.

Other languages (Rust, PHP, Kotlin, etc.) use ? to represent a similar idea: short-circuiting on failure. For many developers, that syntax already feels familiar.

The “just let the IDE handle it” argument

The blog post also brings up the idea that IDEs and AI tools could abstract away error boilerplate.

That’s fine in theory — but in practice, you don’t want language clarity to depend on external tools.

Relying too much on auto-generation or snippets risks hiding the actual behavior, especially in shared or open source codebases.

Clean syntax should be a language-level feature, not an IDE convenience.

Final thoughts

Providing a more ergonomic syntax for error propagation wouldn’t dilute Go’s identity. It would just make the most common code patterns cleaner and easier to write.

A proposal like ?, with clearly defined semantics and full backward compatibility, would:

Reduce boilerplate,
Improve readability,
Still preserve Go’s explicit nature.

What’s your take on this?

Let’s talk in the comments
You can find my website here luise.ac