The problem with everything being single threaded isn't so much that you want to do a lot of parallel processing, but that you don't want to have the occasional fat loop cause the whole engine to start stuttering. If you want butter smooth scrolling while there's (for example) a lot of dynamic content moving around, you want very precise control of the threading so you can get the gnarly stuff done without causing hitches that don't feel right.

The browser, iOS, and Android all use a main thread separate from the thread responsible for scrolling animations.

However, I think it's true that controlling threading in order to perform gnarly work in a separate thread is more ergonomic on mobile than in JS/React.

You'd need to create a Promise that wraps a Web Worker, which would be an unusual thing to use. I don't think most apps need such control over threading in the browser.

If you care about smooth interactions, the browser even in 2026 is not the most straightforward route, nor the route any reasonable small company takes.

It's been many years since I talked to him, but he's an extremely by-the-book guy, so I'm sure he has a process for clearing everything he writes. His reputation does probably provide him a lot of leeway, though. He also has a queue of oldnewthing articles about a mile long and we could probably get years' worth of articles after his death if they let them run.

This is Hacker News. We're supposed to dislike DHH on technical grounds, such as "he made Ruby on Rails exist."

That's on me. I've been giving confident advice that doesn't hold up in practice.

That aligns with your goals of analysing problems, admitting fault and surfacing that through use of clear and concise language. Not just simply wrong — this screams finessed, nuanced, polished communication after an understandable mistake discovered through pressure-tested interlocution.

Deterministic password generator is the only way to go for me. I have my own that takes the site name, username, and a version number and SHA256 hashes it all with a passphrase, and runs the resulting bytes through a simple transformation that produces a strong password with a good character set. Optionally allows me to specify constraints on the password (e.g. which special chars, limited length) for sites with idiotic password rules. If you want to change a password, you incremement the version number. The whole thing is a simple command line dingus that barfs the password out to the clipboard and a note (including the username reminder) out to stdout. I even had claude port it to ios for me.

I've been using this technique for literally all my passwords for about 7 years now and it works great. The only downside is it doesn't help me in situations where I want to either share a password or receive a shared password from someone else.

The really beautiful thing is that you can reconstruct your important passwords completely from memory even after losing your whole config. This saved me recently when my laptop died. git clone / vim a config / remember your passphrase / done

But you still need to store the login and version number for each domain in a database. And provide the secret key. At this point you might as well store the encrypted password along with the rest.

Login and secret key are from memory (especially login for important accounts). Version number is typically pretty small and thus guessable. Like I said, it worked perfectly for critical stuff when my laptop died recently. There is no database. I used the important accounts from memory to bootstrap my way into github where the full config is saved.

I think one thing that has made Go have better dependency hygiene is not merely having "batteries included" in the standard lib, but the early focus on having production-ready implementations of a lot of stuff in the standard lib, as opposed to minimum viable implementations. I used to get a long way with one or two dependencies that would barely fan out at all. It's been a while since I worked on a Go project, so I'm not sure if it's still that way.

I think having production-grade implementations makes a huge difference also. Go’s net/http in the std lib feels like a good example of that, though I’m fairly new to go still. But it seems net/http still gets pretty big updates despite something like Chi being available as an external lib. Odin is doing this as well, even including raylib in the std lib. Odin is even more primed to keep you on the std lib as it doesn’t include a package manager at all.

Odin has been a masterpiece so far! Ginger Bill has a massive update coming in for it Jan 2027 as well. :) I think it's definitely going to take off in the next few years.

I wasn't when I saw they made the exact same stupid error as Python: if and switch are statements, so that you need a stupid ternary operator to do the same.

I think there's money to be made with both, but there's more money to be made by not maintaining two separate models, so ads win.

It's not that rare for games to offer a "remove ads" option for a few bucks. That model doesn't require a lot of extra "maintenance".

I think a few bucks for ad-free brings in more money for most developers, but that still pales in comparison to a recurring subscription model (or models where people keep spending in-app on consumables).

I had a mixed incredible/horrible experience with Claude's AI support agent. First, I suspected there was a particular problem with the API access, and I articulated it and said, "can you give me a way to test this theory and prove that the problem is on your end? Python is acceptable" and it spit out a python test program that proved the problem was on their end. Then it turned a corner and spent 30 minutes insisting that it was going to connect me with a real person who could fix the problem for me before finally admitting that the whole thing was a boondoggle and it had no way to connect me with an actual person, but maybe I should come back to the chat in a day or two and see if anyone noticed and responded.

The real interesting thing was that early on in that 30 minutes, it gave me very clear instructions about how to get a live agent (including a quoted trigger phrase like "I would like to speak to a live agent" or something), which made me believe it was possible, which ultimately made me resist the slow realization that that was a complete fabrication. It was a very effective way to waste my time.

For that matter, why would you pay $1200 for a phone?

It's not a great option. My "old" phone that I use to install junk apps (e.g. I buy some hardware that requires an app to set up) and which mostly sits in a drawer is a 2nd gen iphone SE, and it's getting to the point where I'm going to be forced to replace it, because the OS hasn't been upgraded in a while (it errors) and some apps won't install on it now.

I am running an iphone 12 mini without problems.

I expect I will eventually run into them but at that point I'll just stop upgrading apps.

12 mini is pretty old. I have considered going to a 13 mini, but I sort of hate the idea of spending money on a phone that is already well on the path to unsupported. Then again, the compact options for grapheneos are limited to old stuff too. Sigh.