smarkov

> In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day.

> The history of our main branch alone is almost 100 GB

What value do you get from carrying around all of that history? Your code is changing so rapidly that it looks absolutely nothing like it did a year ago, so at what point are you going to want to see what it looked like back then and every single change that happened to it since? Wouldn't you benefit more from creating a tool that can semantically truncate history entries that are no longer relevant, since even with scn your history will continue to grow out of control?

Maybe you love being the consumer of RSS feeds, but you certainly wouldn't love being the poor bastard who has to parse them.

Even though it's a simple standard that's been around for decades, there are still many sites which serve their feeds with a subtly wrong format. When something doesn't work, users come knocking on your door saying "it works in X reader but not in yours", so now you have to handle that and contribute to the ever growing list of out of spec edge cases that feed readers need to account for.

I never said that PHP was universally used, just that it has answers to most problems.

jQuery has become obsolete these days because the problems it solves have largely been solved by additions to JS, but the interactivity of websites has continued to increase and browsers have yet to catch up to that. Frameworks like React actively fight against the browser rather than work with it by maintaining its own DOM state and constantly creating copies of state for every re-render of a component, along with a bunch of other magic. That's a lot of unnecessary loopholes just to make up for JS's lack of features when it comes to writing reactive UI.

People like to hate on PHP, but PHP provides you with all the tools you need to write a fully working backend, where as JS provides you with half-assed solutions for writing frontend, which is why we have 1000 frameworks and we still can't agree on how to write frontend code. Seriously, we don't even have a convention for writing a simple reusable component with vanilla JS, everyone makes up their own thing. Web components were supposed to be that, but they're a good example of what I meant by "half-assed", because they're ugly, verbose, clunky, don't really solve the right problems, and nobody likes writing them.

Because it's been trendy to introduce a new unintuitive syntax with every new CSS feature.

I am genuinely afraid for the future of CSS as it is becoming increasingly more complex, meanwhile most people haven't been able to properly utilize or understand it for the last decade even without all of that additional complexity.

Remember when we used to be called "web developers"? We then became "software engineers", but forgot the meaning of the word engineer:

> Engineering is the practice of using natural science, mathematics, and the engineering design process to solve technical problems, increase efficiency and productivity, and improve systems.

We don't increase efficiency or improve systems, we just build garbage on top of garbage. Imagine if a structural engineer did the same and built new floors on top of shaky floors. Our buildings would be collapsing on a daily basis.

I get the potential appeal in having a single language do all things, but in practice the front-end and back-end have vastly different jobs and different capabilities, so I see no issue in them being different languages and letting them utilize their strengths. Not to mention the vast amount of complexity you need to involve at some point in order to bring a language to a side it wasn't meant to be in.

I'd love to, but I don't really have a choice at the moment.

Maybe I'm just at the wrong place at the wrong time, but as a software engineer I don't feel like I'm doing any actual engineering and solving meaningful problems, just spaghetti gluing random frameworks, packages and services together. The only problems I get to solve are those caused by the quirks of all these incompatible things being forced to work together. It's draining.

> People have a right to build substitutes and replacements -- I believe in the "Let a hundred flowers bloom" philosopy.

It's a blessing and a curse. Look at package managers, they more or less all do the same thing, with one primary job of "go download some binary so I can run it", yet there's so many to choose from. Every time you read some Linux guide they have to list 7 different ways of installing the same package. It's stupid, probably even more so for the maintainers of those packages because they have to distribute their package 7 different ways. At least I'm glad systemd has mostly become the standard, so you don't have to also see 7 different ways of creating a service.

> `ctx.Value` is an `any -> any` kv store that does not come with any documentation, type checking for which key and value should be available.

On a similar note, this is also why I highly dislike struct tags. They're string magic that should be used sparingly, yet we've integrated them into data parsing, validation, type definitions and who knows what else just to avoid a bit of verbosity.

Huh, I've heard about this for a while but for some reason thought it was strictly regarding phones, maybe because they've been making the biggest headlines about it. Looking forward to it then.

It's not my area of expertise so I might just be delusional here, but from my understanding phones are difficult to make waterproof if they had replaceable batteries because they require a massive lid that spans across the entire phone while having a limited amount of thickness to work with and also because they have some expectations about the depth at which they remain waterproof. You don't necessarily have these constraints with a toothbrush. You can have a small opening at the bottom where you insert a tall battery and have plenty of height left to make a waterproof hatch. You're also unlikely to submerge your toothbrush in more than 50cm of water, like in the event of dropping it in the bathtub.

> Also, anecdotally, I’ve never had a sonicare toothbrush battery die. They still last weeks after many many years of use.

Sure, these exist too, though it doesn't reflect the majority of items which cheap out on all components, including batteries.

I'm not denying that there are some trade-offs, but I'm also not strictly speaking about phones here. Think electric toothbrushes, trimmers, Bluetooth speakers and the other endless amounts of electric things with rechargeable batteries that don't have the space constraints of a phone.

This is a step in the right direction but still doesn't address my biggest concern with e-waste - the battery.

Because almost none of the electronics you buy come with a replaceable battery, the second you buy something and use it on a regular basis it's destined to die and be thrown out within the next 4-8ish years due to the battery degrading and becoming increasingly more dangerous to keep around. Something that might be in perfect working condition and could be used for another 10 years has to be thrown out because of one single component.

I understand that batteries come in all shapes, sizes, capacities, yada yada, but imagine if we had standard rechargeable batteries like we have standard non-rechargeable batteries and things were built in a way where you could easily replace batteries like we could on phones a decade ago. You would double or triple the lifespan of a ton of things.