fl0ki

Star imports aren't the only way, traits are another. Say you impl two traits and they end up both adding a symbol with the same name. Or you bring in an extension trait impl for a standard library type, and now the standard library adds a symbol with the same name as one in the extension trait.

To avoid those problems, you'd have to proactively disambiguate any item with its trait name, which is so un-ergonomic that people genuinely prefer the possibility of occasional breakage.

But was the compatibility table updated?

Just look at the code. Anywhere you like. There's nothing I can say that will be a substitute for seeing it yourself.

I've had to use it as a library sometimes, and it's also really poorly designed as a library. There's no consistent principle for what is exported and what remains internal, so almost anything non-trivial you do may require you to copy-paste parts of the library code because something happened to not be exported. So you must think, okay sure, but in return for that you get a minimal and stable API. Nope! It also has some of the most API churn of any Go module, already up to /v4 and that's only counting the semver-major breakage they bothered to acknowledge, not the many semver papercuts along the way.

etcd is some of the most amateur code I've ever seen, despite being one of the oldest and presumably most mature "infrastructure" projects written in Go.

goBGP is arguably even worse.

I don't have a third place in mind that's even worth mentioning relative to these two.

Mr President, a 4th proposal has hit the General Resolution.

> Keep your CLAUDE.md lightweight and briefly describe what your repo is for [...] Avoid stating ‘the obvious’ things Claude should know by looking at your file system or your repo.

Most people generate CLAUDE.md with /init at least at first, so it gets filled only with the superficial top level things that Claude already noticed during that first run. By this logic, shouldn't CLAUDE.md contain the exact opposite of what /init currently includes?

I completely misunderstood your post, because I have the opposite problem, I've never broken a charge port but I've broken several cables.

Exactly. That said, it's nice to get a notification when it's done.

Try the relatively recent Anker Prime cables, the ones that are both braided and soft. I haven't managed to break one yet, despite breaking several past Anker cables that also claimed to be durable.

I'm still driven absolutely mad by how many devices are being released in 2026 that refuse to charge if they're connected to a port that negotiates USB Power Delivery. They don't fall back to 5V, they just don't charge at all.

Devices like this usually come with an A-to-C cable in the box and that's a warning sign, but an even more twisted version of this is when they come with a C-to-C cable and a Type C charger that does not support PD. That's the only combination they tested, and that's your problem now.

I now carry enough adapter cables that I can deliberately take PD out of the equation just to work around these devices.

Been using this knot exclusively since 2013, it's stood the test of time.

One thing I miss from when I mained workstation-class Linux laptops is indeed just how tinkerable they were, in a way that didn't feel like a compromise because no other workstation-class laptop was smaller, and smaller laptops had limited performance. You could upgrade RAM and replace a HDD with an SSD, you could drop in a PCMCIA card, you could bring interchangeable batteries, etc.

I appreciate that Framework has not only brought that back but expanded on it further, but they've done it at a very different time in the market. Now that maintainability and customizability does come at a compromise to at least one of cost, bulk, or performance. That's not only the case when compared to the Neo, as far as I know it's also the case at the high end compared to a MacBook Pro.

They've set out to do something that would be difficult in any case, but they're also doing it against Apple's advantages of vertical integration and economy of scale. I'm sure I'm not the only person that can deeply respect that while still not feeling any interest in buying any of their available products.

> The Neo is an appliance. The Framework is a tool.

I get where you're coming from in principle, but I'm not sure to what audience this actually applies. If you just want a laptop that can run the software you use, both are adequate as tools. The Framework's greater flexibility only applies to making changes to the tool itself, which doesn't matter if you didn't need to change it to suit your purposes. (And I say that as someone who has built their own Linux & Windows PCs from parts since high school, because I know I'm not the target audience for a Neo)

It's like I consider my Dewalt power drill a very decent tool because it has exactly the modularity I need -- it even has interchangeable batteries -- and it wouldn't even occur to me to call it an outright appliance even if another power drill offered more customization for some niche use case. The Neo is an adequate tool for many people even if other tools do offer more customization or maintainability.

This would be a much stronger argument against using an iPad for productivity, because many people simply cannot run the software they need, or only at a significant expense to productivity and quality of life. I use iOS devices only as communication and media terminals, and even then I would struggle to call them appliances, they're still tools for their particular tasks.

It's even weirder than that sometimes. For example, Subnautica on Steam has a hard dependency on Steam (whether or not you would call this DRM), but the exact same version number of Subnautica on Epic Game Store only checks for a command line flag and can easily be archived out. Despite that, it's not for sale on GOG.