Users: I never said thank you.

Debian: And you'll never have to.

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.

Oh not only to the stdlib but to any lib! I thought that was crazy when you mentioned it but after reading the post I agree it’s a pragmatic approach. By the way Java does the same! The problem can be avoided by avoiding “star imports” in both Java and Rust, and at least in Java star imports are very rarely used for this exact reason (I remember my horror when I couldn’t call a method of List that I knew existed and it turned out a “import java.awt.*;” was the reason, that was a pain to figure out before AI and convinced me to never use star imports again).

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?

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.

just curious, what problems do you see with gobgp?

(I have only a rather basic familiarity with go, but was considering gobgp for an infra project...)

Not speaking to their code, but to start GoBGP has the worst performance of any BGP daemon by a large margin [1].

[1] https://elegantnetwork.github.io/posts/comparing-open-source...

Garbage collected languages like Go will always have worse performance than lower level languages like C (frr and bird are implemented in C).

Gobgp is great if you want to embed it directly into a Go app though. Talos Linux has done that recently.

Nope, it is a matter of skill as well.

https://github.com/ixy-languages/ixy-languages

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.

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?

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 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 have had a few failures and I can only assume it's the second one? I have one on a thinkpad that only works if you hold it in the right position

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

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.