Sometimes real estate agents do a lot. Anecdote of course, but my real estate agent spent a few hours basically every weekend with us for like 2-3 months as we toured 25 houses, went over ~10 inspection reports, and made 3-4 offers. And he and his team got roughly 20k. In a better housing market I think they do a lot less, but I know ours did a lot of work.
And yet I personally know more people who own iPhone minis (myself included) now in 2026 than that own pixel phones of any model. I think the data is distorted by the fact that most people who want things like that also don’t typically buy new (especially with cars). I did buy my iPhone 13 mini from Apple directly, but I bought it after the 14 line had already been released.
I loved the iPhone 4 format factor, but prefer more recent and larger editions for battery life and battery longevity.
My only gripe with the 6.7 inch form factor would be solved if someone would just sell me a bigger hand. I can’t hold it one handed and reach the far corner of the screen without some obnoxious accessory like a Popsocket bolted to the back thereby making it impossible to use on a flat surface or fit in a pocket.
Come to think of it, Zaphod might have been on to something with that third arm.
I am aware. My point was basically that the people who wanted them weren’t lying, they really love them, and are willing to keep them for years even though they are getting slightly old now. I’m imagining this doesn’t show up in first year sales numbers in a similar way to how the things people say they want in cars typically drive used market buying not new market purchases.
I’ve tried to validate this hypothesis, but run into problems finding the data. Do you know where to find currently active numbers by model? I’m think something like browser market share charts. I’ve only been able to find numbers from the year they were released, and even that was as a percentage of total sales, not raw numbers.
My hypothesis is that minis (13 mini and 12 mini) are over represented in active phones compared to other models of that generation.
I think you are right because people who bought minis got them for a specific reason and now there is just nothing in the market that can pretend to replace it.
My own mini has not been upgraded to latest iOS but I know it is in short probation before it gets really unusuable. It's pretty bad with swapping already because Apple was so stingy with the godamn RAM (it's insane how much modern apps use for not much more utility).
The problem is that I have really no clue what to buy, even if I were to go Android.
I just can't find a phone that I think merit the tradeoffs of form factor, I just don't have much use for all the modern gimmicks. A better battery life would be nice but it's not even a big deal in my case.
The problem is basically the same as for cars. People are buying larger phones with many useless features for social status reasons or aspirational/fashion statement.
The smartphone as a tool was a finished product a long time ago but now they keep adding all kind of extra stuff that even manage to kill the initial feature of conveniently fitting in an average pocket.
I would compare that to Victorinox Swiss knifes: there are a handfull or reasonably sized models with all the tools you are likely to need for small tasks and there are monstrosities that have 100+ tools that are so large, even using them as a knife is inconvenient.
If people would buy Victorinox Swiss knifes like they buy smartphones, most would get the largely useless bigger ones.
Most people are not very rational and make purchasing decision not on their needs but because of trends, marketing, social status, peer pressure, etc...
When a market becomes very large and target the whole population at once, products tends to get pretty bad because they are not focused on specific use case and try to please everyone, really pleasing no one in the end. Since there is not much other choices than to follow, people deal with it and that's that.
> In fact, nearly everything terrible about cars in the last decade can be traced to regulations in some way.
I think the reason we even need backup cameras now is that visibility is so poor on modern vehicles. I think that in turn is due to increasing the height of the bottom of the windows for better airbags. I’m sure it’s great in a crash, but visibility is also a safety concern.
Not all of it is regulations though, but lot of common complaints.
Rwd is definitely sketchier in certain circumstances, especially going uphill in low traction. Also pretty bad in the snow generally. but I’ve only had issues going around corners when it was very wet and I was driving faster that the speed limit. If you are running into traction issues driving normally (ie not flooring it) I would recommend having your tires and alignment checked, even with RWD that should not be happening in my experience.
I could be wrong, but on a lot of mobile SOCs all of the modems are in the same chip as the CPU. I think you would have better luck removing the connection to the antenna
I am pretty sure the expectation would be different if Kagi search could be self hosted. Linux people have come to expect open source for code they run on their own machines. Historically closed source Linux software has run into a lot of problems with dependency version mismatches as libraries get updated through the distributions package manager.
Sponsorships are a supplemental income stream, though, right? They have paid services in addition as I understand it. So covering several full time developers seems pretty good sponsorship wise, when the maintenance should be fairly simple at this point given the maturity of the offering and the tech stack. It’s not like they have to keep up with security vulnerabilities or a mobile version update churn.
They just sell lifetime licenses to extra content at a fixed (relatively small) fee.
> Because every project is different and the way independently authored pieces of code interact can be complex and time-consuming to understand, we do not offer technical support or consulting.
My guess is that the author hasn’t fully frocked how go interfaces work yet. Go errors implement the error interface, but that just makes them interoperable, it doesn’t mean that’s all they are.
Correct me if I am wrong, but does it not mean that they are type-erased though? The whole point of returning an interface is to perform type-erasure.
If I have
struct S { X int }
func (s *S) Error() string { ... }
but I return it as an error:
func DoStuff() error
Then all the caller gets is an error interface. Without downcasting (`.(T)`/`errors.As`), you can only compare it to other instances (if the library author provided them) or see the string representation.
Yes, that's correct. The interface limits what guarantees the caller has about the type without runtime introspection. I don't think that really makes it any harder to handle expected error conditions though, since type assertions return a boolean. eg:
if myErr, ok := err.(MyError); ok {
// handle MyError case
}
...
But you should always expect that there could be errors you don't expect to exhaustively handle with special logic.
When people say they want sum types, they generally mean they want both sum types and exhaustive pattern matching. Either of these features on isolation are nice to have, but both together are incredibly powerful to the point where having just one is almost not worth it.
Is this what people mean by Enums? I must not have used languages where Enums have those powers. I have often been very confused by statements people make about Enums so that would make some sense.
How do sum types address the problem that the underlying type (int or string or whatever) is totally capable of describing values other than those your code was compiled with? I'm mostly thinking of version skew with something like a dynamic library or plugin, although casting would probably also have the same effect.
Yes, this is generally what people mean when they talk about enums in modern languages.
The in memory and ABI representation of enums/sum types is language dependent.
In Rust, an enum is equivalent to a C union where there's a discriminant value which is an integer of sufficient size to cover all variants (u8 is sufficient for 255 different variants), followed by as many bytes as the largest variant (a tagged union). Mucking around with the underlying bytes to change the discriminant and cause type confusion is UB. All the same strategies you'd take in C for versioning and ensure binary backwards compatibility would apply. When exposing these you would likely want a higher level abstraction/self-describing wire format, if you don't have control over both sides of the ABI boundary.
Other higher level languages do this for you already. I believe Swift is one of those, where it has a COM-like ABI layer that the compiler makes injects transparently to correctly interact with a dynamic library, handling versioning for you.
I am of the opinion that we need a new attempt at a multi-platform, language-agnostic, self-describing ABI, "COM for the modern world". I think some people have talked about using WASM for this.
Keep in mind that the concept (pattern matching, sum types) is not tied to how they are represented (Scala has both, but they are represented different to what I described earlier; IIRC it uses inheritance to represent the variants).
The problem is that this makes enums non-enumerable. They need to be represented as a range or union type to do that. I am pretty sure I know why/how Go ended up like this because it’s inherited behavior from proto, wrote a large comment later down the thread explaining why.
The api surface is relatively small, but the capabilities you get from it (http serving, json parsing, crypto, in addition to table stakes like io, args, flags etc) are very high. Having a small api surface is why you need to use primatives so often, but the upside benefit to that is there is less domain specific knowledge, since you end up using familiar types and libraries in more of your code.
reply