Rob Napier

Swift and Go. Love 'em both. They make me mad in completely different ways. Infosec as required. robnapier.net

Cocoaphony Blog: https://robnapier.net
GitHub: https://github.com/rnapier
Twitter (defunct): https://twitter.com/cocoaphony

Last Notes

2026-04-13 18:23:54 UTC

- reply

I’m always reminded of working on telephone switches in the 90s, designed in the 70s. Protected Call Store memory was baked into the hardware, memory that persisted between reboots, and a fairly simple annotation assigned certain variables to that pool.
Similarly, when I worked on mail inserters, crashing reboots were not an excuse to pause. Paper was still flying. Software was expected to just recover.
Both iOS and OS X started down that old road, but never took it seriously enough.

2026-01-18 02:45:15 UTC

RE: https://dice.camp/@johnzajac/115845954658479816
I spent a lot of time in the 90s working on Y2K. It wasn't a huge panic. It was just a slice out of everything else we spent auditing code. It wasn't "spend 80 hours a week fixing this." It was just boring. Incredibly boring. And we made it be ok by being bored and fixing stuff.
And the one thing I never thought would happen was that people would say it was never a problem. Oh good grief, it was a problem. All over. We just fixed it. Like we thought grownups should do when there's a problem.
#note1a2r…anaj

2025-11-18 01:25:50 UTC

If you're into trance, or have any interest in the intersection of coding and music, spend some time with Switch Angel. There's not a lot to the channel yet, but I'm hooked.
https://www.youtube.com/watch?v=iu5rnQkfO6M

2025-07-25 13:26:13 UTC

I've heard people use "brownfield" before to mean "extremely broken and buggy code bases" as a joking reference to "greenfield," but more and more I'm seeing it as "any code base that has existed for more than a few months." And that bothers me.
Production code is not a "brownfield." It is a jungle. It may have dense undergrowth and be hard to navigate at times, but that's because it's alive and it's supporting living things. That's the goal of software. That's what working code looks like.

2025-06-22 20:17:13 UTC

- reply

Agreed that coding assistants are definitely lowering the bar (in a good way) for non-devs to build their own tools. I've seen quite a lot of that, and it's a great thing.
I think some folks are scaling that incorrectly to "AI, build and deploy a replacement for Netflix, I'll come back in an hour." This is very related to how folks confuse prototypes with "almost ready to ship."

2025-06-22 20:03:19 UTC

- reply

But I am with you about "vibe coding." I expect that's a fairly short-lived thing. When I see people who are really successful with it, it turns out there was often a *lot* of planning that went into that "vibe." :D

2025-06-22 19:51:40 UTC

- reply

(And yes, AI hallucinates. And also, when you research things on the internet, the internet hallucinates. And when you study things in books, they also sometimes are just flat wrong. There are definitely differences, but it is not a fundamental break with the past.

2025-06-22 19:50:11 UTC

- reply

Of course when higher level languages were first developed, senior engineers did not feel that the issue was an acceptable level :D
I'm seeing some junior devs get in way over their heads following AI advice. (I'm kind of developing a stock lecture about it…) I'm also seeing junior-to-intermediate devs use AI to explore and learn deep things they wouldn't have dared before. I'm seeing the dig into details that before they'd have left as unknowable.

2025-06-22 19:41:14 UTC

- reply

But to Beck's point, I think to a first order, you should think of coding assistants like a higher-level programming language, not a complete reinvention of programming. I find that most of the usual skills still apply, even when they're running at their best. And to "how will junior devs learn the low level skills I know," I'd say the same way most devs learn assembly language. They don't. And it's mostly fine.

2025-06-22 19:38:50 UTC

- reply

I'm sure that StackOverflow is a huge input for programming information, and I know I'm not alone in dramatically reducing my time there. After writing over 5700 answers over 15 years, I haven't answered anything in 2025. I do expect this to become an existential problem for the models across a lot of fields.

2024-11-20 17:32:53 UTC

There are some Swift features that are just a delight, and `some` in parameter types is one of them.
I was just working on a bunch of code where everything expects arrays. Totally reasonable. But I wanted to introduce `chunks(ofCount:)` to replace our home-grown `chunks(of:)`, and that makes things lazy and changes the types.
A few mechanical conversions of `[?]` to `some Sequence<?>`, and boom, more flexible without adding a ton of syntax noise.

2024-08-05 02:31:48 UTC

- reply

Simple async replacing completion handlers. Good. Yes. Do this.
Sendable. Making types thread-safe has sussed out quite a few real race conditions.
A Task or [String:Task] property to let multiple requests for the same thing complete together and all get the same result. This is very good. This is something I didn't even really try to solve w/ GCD.
While actors often bite me, Apple's Quakes demo is very good. I use its lessons often.
2/2
https://developer.apple.com/tutorials/app-dev-training/caching-network-data

2024-08-05 02:31:41 UTC

I talked a bit this weekend about the pieces of Swift concurrency that confuse and frustrate me. Mostly it winds up being actors. I think they're just not really baked yet.
And for similar reasons, a lot of things that come under the umbrella of "isolation." I think they're like protocols with associated types for the first several years. And maybe, like generics, this stuff will eventually work out.
But I also want to talk about what I think is working in Swift concurrency.
1/