fl0ki

Users: I never said thank you.

Debian: And you'll never have to.

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.

This isn't the only way a Rust stable update can break your compile. It can also happen simply because they add a symbol to the standard library, and that isn't even protected by language editions.

https://predr.ag/blog/some-rust-breaking-changes-do-not-requ...

"Never add anything" isn't a tenable position, and in practice the breakage hasn't been bad enough to need special treatment yet.

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.

Workers seizing the means of production is out, workers seizing the product is in.

I think a big difference is that the less unsafe you want in your own code, the more you rely on crates to provide a safe abstraction for unsafe code in a centralized place where soundness holes are likely to be found.

Of course it was always understood that you could have bugs in C libraries and some of them may include memory unsafety, but the culture is very different when there's no explicit way to demarcate the parts of the code most deserving of scrutiny.

I was also worried about the plastic tongue, but I have never managed to break one. In contrast, I have managed to irreperably damage the exposed metal contacts on multiple Lightning cables. If you'd asked me which should be more durable, I would have predicted Lightning, but my experience has been the exact opposite and beyond any doubt.

To be fair, even state of the art of high-speed data cables are thick and relatively inflexible. I simply wouldn't want every cable to be a high-speed cable if that meant they were all chunky. I do agree that it should be clearer at a glance what you can expect from a port or cable.

Async ruined Rust for me, even though I write exactly the kind of highly concurrent servers to which it's supposed to be perfectly suited. It degrades API surfaces to the worst case :Send+Sync+'static because APIs have to be prepared to run on multithreaded executors, and this infects your other Rust types and APIs because each of these async edges is effectively a black hole for the borrow checker.

Don't get me started on how you need to move "blocking" work to separate thread pools, including any work that has the potential to take some CPU time, not even necessarily IO. I get it, but it's another significant papercut, and your tail latency can be destroyed if you missed even one CPU-bound algorithm.

These may have been the right choices for Rust specifically, but they impair quality of life way too much in the course of normal work. A few years ago, I had hope this would all trend down, but instead it seems to have asymptoted to a miserable plateau.

Like I said, if you prefer an integrated graphical UI, you can file feature requests against the one you prefer. What git itself does makes a lot of sense for the canonical CLI tool to do, though even then you can propose or prototype changes if you have ideas. This is how projects like jj started in the first place.

If that's the kind of UX you prefer, please consider filing a feature request against your git UI of choice. My point is that git itself already has the core capability, and how convenient it is to use usually depends on your editor. (e.g. in vim, dd to cut a line and p to paste it in a new position is a very quick way to reorder)

> I think it would be great to have the ability to easily reorder/modify commits while in active development

Take a look at `git rebase --interactive`.

I only agree if you have a bounded dataset size that you know will never grow. If it can grow in future (and if you're not sure, you should assume it can), not only will many data structures and algorithms scale poorly along the way, but they will grow to dominate the bottleneck as well. By the time it no longer meets requirements and you get a trouble ticket, you're now under time pressure to develop, qualify, and deploy a new solution. You're much more likely to encounter regressions when doing this under time pressure.

If you've been monitoring properly, you buy yourself time before it becomes a problem as such, but in my experience most developers who don't anticipate load scaling also don't monitor properly.

I've seen a "senior software engineer with 20 years of industry experience" put code into production that ended up needing 30 minute timeouts for a HTTP response only 2 years after initial deployment. That is not a typo, 30 minutes. I had to take over and rewrite their "simple" code to stop the VP-level escalations our org received because of this engineering philosophy.

> Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants.

I get where he's coming from, but I've seen people get this very wrong in practice. They use an algorithm that's indeed faster for small n, which doesn't matter because anything was going to be fast enough for small n, meanwhile their algorithm is so slow for large n that it ends up becoming a production crisis just a year later. They prematurely optimized after all, but for an n that did not need optimization, while prematurely pessimizing for an n that ultimately did need optimization.

Yeah, I make it a habit to read the changelogs of every update to every direct dependency. I was anticipating this change for years, thanks for doing it!

My best professional relationships are between people who are confident enough to take direct feedback and appreciate it rather than resent it.

However, my worst professional relationships are with people who will rebuke your feedback whether you Crocker it or not. If you're direct, they'll say you should have been more diplomatic about it, but if you're diplomatic, they'll say you're being dishonest and should have been direct. There is no right way to approach it, these people will always find a way to criticize the delivery, and to delegitimize the feedback because of it.

This seems as good a thread as any to mention that the gzhttp package in klauspost/compress for Go now supports zstd on both server handlers and client transports. Strangely this was added in a patch version instead of a minor version despite both expanding the API surface and changing default behavior.

https://github.com/klauspost/compress/releases/tag/v1.18.4

Try Sikarugir for PC gaming on macOS. It runs everything I've cared to try, with little or no tweaking.

https://github.com/Sikarugir-App/Sikarugir