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.
No they won't. They are generally faster in throughput than any non-gc application that isn't heavily hand optimized. Their problems are higher memory usage and unpredictable latency, not speed.
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.
> 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?
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 don't have a problem with USB C cables, and even if I did it wouldn't be a big deal. The cables are cheap compared to the devices they charge. It is broken USB-C ports that frustrate me about them, or ones with worn out clips.
What way are you breaking them? The two failure modes I've seen are the port getting full of pocket lint for phones (easy to fix) and the port ripping off the PCB. The second one is a design issue where some ports are entirely surface mount rather than having the grounding pins go through the pcb to anchor it on.
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.
> 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.
True, I was being a bit loose with my terminology. Some tools reward customization more than others. Machine tools and 3d printers are often used to produce parts, mods, and upgrades for themselves, for example. Screwdrivers aren't usually used to work on themselves though.
The principle I was trying to express is that a Framework (and Linux, for that matter) is a tool more like a mill or an older 3d printer from the RepRap era. You will get the most out of it if you spend time customizing it, altering it, upgrading it, understanding it, etc. A MacBook Neo is a tool more like a screwdriver or a power drill. It is immediately fit for its purpose, even if that purpose isn't quite as wide ranging.
It feels a bit odd to compare them directly across categories. The MacBook Neo feels like it should be compared to a Chromebook or a cheap Windows laptop, not a high-end Linux-first upgradable machine. That's like comparing a Dewalt power drill to a 1930s drill press. They can both drill a hole... but they're just not the same tool, and I (personally) wouldn't expect to use them in the same way.
Framework's hero image when you build the laptop is someone removing the keyboard to tinker with the machine.[1] If you don't intend to do that, then yeah, it's probably not the choice for you. If you are indifferent between macOS and Linux, then it's probably not the choice for you.
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.
It's a bizarre distinction, because "tool" does not imply "highly customizable" or even "repairable." In fact, even the distinction between "appliance" and "tool" is odd, since those are nearly synonymous in everyday usage, and both strongly imply a device designed for a narrow use case.
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.
