Forem: Lex Nwimue P.

Rust got 'pub' wrong

Lex Nwimue P. — Wed, 24 Dec 2025 17:44:09 +0000

The pub keyword in Rust is used as an access modifier to make items—such as functions, structs, enums, traits, and modules—accessible outside of their defining module. In that sense, it behaves similarly to public in many other languages.

However, one major difference—especially noticeable if you’re coming from JavaScript—is the default behaviour.

In JS/TS, methods on a class are public by default (assuming you don’t explicitly mark them otherwise using # or the private keyword). The underlying assumption is that most class methods should be accessible, so there’s no need to constantly annotate method signatures with a visibility keyword. You could call this convention over configuration.

Rust could have borrowed this idea and arguably become even closer to perfection than it already is. But it didn’t. Instead, Rust went in the opposite direction: private by default, public by explicit declaration.

The result is that you often end up with code that looks like this:

See it? A literal littering of pubs.

If the default behaviour were reversed, we might end up with cleaner-looking code—similar to how Rust handles the mut keyword. Variables are immutable by default, and when you explicitly add mut, it immediately signals to the reader that this value is going to change somewhere later. That signal is psychological as much as it is technical.

Right now, pub doesn’t quite have that same signalling power because it appears everywhere. It becomes visual noise. If, instead, Rust had opted for public-by-default, then explicitly marking things as private could have had the same effect that mut has today. Seeing a private keyword would immediately tell the reader: “This is intentionally hidden; don’t depend on it.”

In other words, the code would read more like:

“Everything here is meant to be accessible—except these specific things.”

Rather than:

“We want this, and this, and this, and this… to be public.”

Important Clarification (Where Rust Actually Differs from JS)

One thing worth correcting is why this comparison feels slightly off. Rust’s visibility is module-based, not class-based. In JavaScript (and many OOP languages), visibility is scoped primarily to classes. In Rust, visibility is scoped to modules, which act as explicit API boundaries. This means Rust isn’t just protecting fields and methods—it’s protecting entire namespaces and architectural layers.

So the choice of “private by default” isn’t just stylistic. It strongly encourages:

deliberate API design
minimal public surface area
fewer accidental breaking changes
clearer ownership of invariants

This is especially important in a language designed for large, long-lived systems and libraries.

So… is Rust wrong here?

Probably not.

But is the ergonomics debate valid?

Absolutely.

Rust trades verbosity for correctness and stability, and while that choice makes sense from a language-design perspective, it does come at a readability cost—especially for people coming from JS/TS, where public APIs are often implied rather than declared.

Whether that trade-off is worth it depends on what you value more:

visual cleanliness
or uncompromising explicitness

Rust very clearly chose the latter.

What do you think?

Rust Slices

Lex Nwimue P. — Tue, 23 Dec 2025 02:25:08 +0000

Most of my writings about Rust come from a JS/TS developer’s point of view. Intuitively, when you learn a new language through another, you tend to map concepts between the two. For example, a struct in Rust might map to an interface or type in TypeScript. Doing this makes it easier to consume knowledge in the new language because the concept suddenly feels familiar. But this pattern of learning introduces a subtle problem.

Once you get used to constantly mapping ideas, it becomes harder to truly grasp concepts in the new language that don’t have a direct equivalent in the one you already know. This was the hurdle I ran into with slices in Rust.

This short article assumes a basic understanding of Rust concepts such as references, borrowing, and ownership.

A common Rust pattern
In Rust, it is generally best practice to use an immutable (read-only) reference when writing a function that does not need to mutate its argument. To illustrate this, let’s write a function that accepts a full name and returns just the first name.

We might end up with something like this:

fn get_first_name(full_name: &str) -> &str {
    full_name
        .split_whitespace()
        .next()
        .unwrap_or("")
}

What’s going on here?
The get_first_name function:

Borrows a string slice (&str); it does not take ownership.
Splits the string by whitespace into words.
Takes the first word (if any).
If there are no words (i.e. the string is empty or contains only spaces), it returns "".
It returns a slice of the original string, not a new String.

Everything makes sense… except that last bullet point. What do you mean “it returns a slice of the original string, not a new string”?

Let’s ~~unwrap~~ unpack 😌😉
What does “returning a slice” actually mean?

Let me say the same thing using different words: The function is not creating a new string. Instead, it is simply pointing to a portion of the existing one. So if our original string is "Lex Luthor", a slice could refer to:

"Lex"
"Luthor"
"thor"
"ex Lu"
or even "Lex Luthor" (the entire string)

All of these are just views into the same underlying string data.

The JavaScript mental model (this helps)
If you’re coming from JavaScript, your brain probably jumps straight to substrings. Yep—that’s a very good instinct.

A substring is a part of another string. Its start and end indices fall within the bounds of the original string. If the start is 0 and the end is string.length, then the substring represents the entire original string. That’s conceptually how slices work in Rust too—but with one important difference:Slices are references, not new values. This distinction is crucial.

Why slices exist at all
If you already have a reference to a string, and you want to refer to part of that string, you could allocate a new string and copy the data into it. But that would mean:

allocating new memory
copying bytes
doing extra work you don’t actually need

Rust looks at this and says: Why not just reference a portion of the original data instead? That way there is no copying, no new memory allocation, and everything stays fast and explicit. That is exactly why slices exist.

Slices aren’t just for strings
Slices work with arrays too, and the syntax looks very similar.

With strings:

let original_value = String::from("Hello world");
let slice = &original_value[1..7];

Here, slice is a &str pointing to "ello w" inside original_value.

With arrays:

let ages = [13, 21, 37, 4, 55];
let slice = &ages[2..4];

In this case, slice is a reference to part of the array: [37, 4].

Slices use the form &original_value[start_index..end_index] where start_index is inclusive and end_index is exclusive. So you slice from start_index up to (end_index - 1). You can also omit one or both indices:

&value[..] → the entire value
&value[..3] → from the start to index 2
&value[3..] → from index 3 to the end

Final thoughts
Slices felt strange to me at first because I kept trying to force them into familiar JS concepts. Once I stopped thinking in terms of “new values” and started thinking in terms of references to existing data, everything clicked.

If you want to go deeper, the official Rust book explains slices beautifully and in more detail here, including one powerful example why you should use slices:

👉 https://doc.rust-lang.org/book/ch04-03-slices.html

The void

Lex Nwimue P. — Sun, 21 Dec 2025 00:52:26 +0000

Hello.

This would be my first article in what is, hopefully, a series on my entanglement with the Rust programming language. Seeing as I like to speak to myself sometimes, you will find leakages of my mental monologues in here—and they might have absolutely nothing to do with the subject matter. No vex.

That said, I should probably start by stating that I’ve had my fair share of experience with programming. My journey began a long time ago, back in primary school around 2004/2005 (the date could be off by a year or two), when I first saw a computer at my school, Meved Model International School, Oginigba, Port Harcourt.

I remember there was a short queue of my classmates waiting to “touch” the computer. Like any young child, I was intrigued. When it was my turn, I pressed the letter G. I remember this insignificant detail weirdly well. I had no idea that I was supposed to press and release the key, so I held it down, and a long sequence GGGGGGGGGGGGG appeared on the screen before I was quickly asked to stop. LOL. I moved on and made way for the next kid.

It wouldn’t be until 2010 before I had access to a computer again. This time, I accompanied my friend (and neighbour), Kemah Barida, to a computer centre in Bori. He was already familiar with using one—I can’t recall where he learned, maybe at school—and he paid for time while I watched. There were several computers in the room, and two kids—likely the owner’s children—were playing what looked like very colourful games in the background. (It was really more of a room than a facility, but I digress.) In my 12-year-old head, it felt like pure luxury.

I don’t remember exactly what Kemah went there to do, though now that I think about it, it might have been research for a school assignment. What I do remember is basking in the euphoria of seeing—and possibly touching—a computer again. I replayed the scene excitedly in my head for the rest of the evening.

Fast forward about two years later. I had graduated from secondary school, and my mum paid ₦9,000 out of an agreed ₦12,000 for me to take computer lessons at David’s Investment, 51 Mayor Street, Bori. I trained under Barisiletam (Asile, as we fondly call him), who would later become my mentor, my first boss, and—years later—the person who gifted me my first laptop. I was beyond excited to get started. Also, my mom never really paid the ₦3,000 balance. Either she did, and Asile wouldn't take it or something else, I couldn’t say.

Over the next few weeks, I was introduced to the typewriter. Disappointingly. :(

I typed the same text repeatedly on blank A4 sheets. There were folders full of these papers—typed by my predecessors—some of them so neat and error-free they made me jealous. I, on the other hand, always found a way to mess up somewhere on the page. I never completed a full page without errors before I was finally moved on to the next stage of my training: actually using a computer.

Unfortunately, I’m not very good with hardware, so I can’t tell you exactly what machines we used. What I do know is that they were desktop computers with massive CRT monitors. We had a couple of LCD screens too, but those came a bit later, I think. The keyboards were clunky and loud, but the noise made us feel like badass typers—it amplified our perceived dexterity.

Almost immediately, I was introduced to Mavis Beacon, where I spent the next couple of weeks. I vividly remember the first time I completed a full session in Penguin Crossing. I was amazed—I’d been trying for weeks. At that point, my typing speed hovered around 30 words per minute. My last measured peak was about 80 WPM a year or two later.

At this time, I knew almost nothing about programming. Still, this experience alone was enough to make me abandon my plan to study medicine in favour of computer science. Three years later, I’d head to university to do just that—and finally learn, in a classroom setting, what programming really, really was.

I wrote my first “Hello, World” program in 2016 at Rivers State University, Port Harcourt. Guess what language it was in. Of course—Python. It was the first programming language we learned, and I studied the documentation a lot, despite understanding less than 10% of what I was reading.

Eventually, we moved on to C++, then Java—the language I first explored extensively. By 2019, I was rounding off school and building an automated attendance system using face detection and recognition. I never fully completed the software, and I didn’t know enough about GitHub at the time to store the code properly, so it eventually got lost on some computer in the school library.

What I failed to mention is that by 2018, I had done my internship at elitePath Software. That was where I first properly learned HTML, CSS, and some JavaScript. For the first time, I found a language I could naturally resonate with: JavaScript. I fondly referred to it as the language of the gods because of its many quirks. That introduction—eventually leading to Node.js—guided me into backend development, which is what I would go on to build a career in.

I later dabbled in C#—not for very long, but long enough to land a spot on Microsoft’s .NET Show, where I was invited to speak about the challenges of distributed system design. That video is still on YouTube. After my time with C#, I started thinking about exploring a different space from the traditional API development I’d been doing for a couple of years. That curiosity eventually led me to Rust.

Between work and personal commitments, it’s been difficult to fully immerse myself in the Rust ecosystem. But in recent weeks, I’ve decided to be more intentional, and I’ve taken things up a notch. That’s why tonight I decided to write about Rust’s unit type (). However, since I’ve made this article unnecessarily long and delightfully distracting, it might be best to save that for another article—probably with a very similar title.