Last I checked, depending on one’s needs, used EVs are among some of the best values in the US used car market. Their prices are closer to what prices on used gas cars would’ve been had the market not been turned on its head during the pandemic.
The main caveat is that available models are heavily weighted towards “compact” (RAV4 sized) SUVs and larger. There aren’t many little Prius/Fit/Soul type town car models around which is a bit paradoxical with that being the use case that EVs have been well suited to for the longest time.
The problem is the "gas station mindset", where people are only able to view EV ownership through the lens of "drive till empty then fill up".
A 250 mile round trip to the beach becomes unthinkable because the gas station mindset dictates that they will have to spend 30-40 minutes at a charger on the way home.
The reality of course, is that you charge on L2 while at the beach, or stop for a quick 5-10 minute buffer charge to get you home.
So everyone is all "I need 350-400 mile range or its totally a non-starter". Its just all around confused thinking.
It’s almost maybe not a bad idea to take a ~30m breather on a 250m trip. Good opportunity to grab a bite to eat too since many chargers are situated near rest stops and restaurants.
It’s not just old EVs that are cheap, it’s 1-3 year old low mileage off lease models too.
My numbers may a bit out of date but for example, depending on the trim and mileage, the Nissan Ariya can be be had at between $15-$25k (with MSRP being over double that) and they only started selling those in 2023. Ariya’s thus far have shown great battery degradation too, with high mileage drivers (Uber etc) reporting 99% capacity.
And that’s just one model. There’s also Kia EV6/EV9, Hyundai Ioniq 5/9, VW ID.4, Mustang Mach-E, and several others of a similar vintage that are similarly deeply discounted despite low miles.
It’s thanks to the many lease deals, tax rebates, etc bringing down their market value.
I had heard that prices went up as a result of the oil supply crunch.
Not seeing where the downgrade is, though. Even the cheaper trims of Ariya are nicer, better equipped, and more powerful than any new car in the low-mid 20s price range and the used ICE car market is entirely nonsensical, with some 1-3 year old used entry level models selling for almost as much as their new counterparts and popular 10 year old models that already have half their lifetime miles selling for north of $20-$25k.
Because to purely swap for an EV I have to take my well specced current car, sell it, and buy a lesser specced EV (unless I bring additional cash to the table). And only then might I break even after years of lower maintenance / refueling costs.
This year I bought a 5 year old compact electric SUV with 94% reported battery health (gets about 20 miles under its EPA-estimated range) for under $12k.
Your point is false. Batteries last long enough, there is no massive degradation at 10 years, and you have no data to prove that assertion. Whether you believe it or not, heh, that's up to you, believe what you want. Facts are facts.
> Industry experts think newfound knowledge of battery durability is a game-changer for consumer confidence in EVs
> Richard Symons recently took his five-year-old Tesla Model 3 on a 260-mile road trip across England without having to stop for a charge.
> A new electric vehicle could make the trip no-problem. But Symons’s car—which he has affectionately nicknamed “Miles”—has logged 247,000 miles and is still up for frequent long-distance drives. “They are proving themselves to be exceptionally reliable,” Symons said.
> After five years on the road, the average EV will still be able to drive up to 95% of its original range, according to Recurrent, a data-science company that provides a battery-monitoring tool for EVs—better than many in the auto industry expected.
> When early EVs hit the market, buyers’ concerns were well-founded. Roughly one in 12 EVs built from 2011 to 2016 have had to have battery replacements. But new data shows that more modern EVs are doing better so far. Among EVs built from 2022 on, 0.3% have had battery replacements, according to a 2025 study from Recurrent.
> 250 million is a lot. That’s how many miles Recurrent vehicles have driven since they connected to our services to monitor their EV performance and health. There are some optimistic, high level takeaways in all this data. For most EVs, the lithium ion batteries are in quite good shape and only 1.5% have been replaced in Recurrent's community of 15,000 cars. Battery replacements due to excessive degradation are very rare. Heat, high voltage, and extreme state of charge degrade batteries the fastest. We generally see 1-2% range degradation per year.
(my 2018 Model S with ~150k miles on it has ~7-8% degradation after 8 years of aggressive use, the majority of charing done at fast DC Superchargers across the US; the only maintenance it has needed has been tires, wiper blades, wiper fluid, and a replacement battery pack heater to condition the pack for fast DC charging, which has been obsoleted in newer revisions)
You believe the degradation is material, all of the evidence says that it is not. I suppose we agree to disagree then. I don't have strong feelings on the topic, if folks want to keep paying for fossil fuels at these prices, or higher prices, versus driving an electric vehicle, good luck to them. That's a choice. Natural consequences are important to encourage better outcomes.
My citations specifically speak to your example as being no longer relevant due to state of the art battery pack management. Please read them again. No one builds air cooled battery packs like the leaf had that were highly prone to failure. Battery pack architecture and management operations have continually been improved over the last two decades to improve longevity.
I really wish Honda would release the CRV plug-in hybrid in the states. But all we get is some weird hydrogen monstrosity. China has all electric vehicles with gas generators to charge the battery. That would make this work for my scenarios too.
Absolutely. I think that over-reliance on analytics has had a similar effect; compared to relying primarily on proper usability research and in-person user studies, doing that creates a detachment and distance that further removes the project from reality.
How great the impact is depends on how management uses the data. If they use it add resolution to broad strokes from studies and the like, there may be no negative impact at all, but in my experience it's much, much more common for management to read analytics like tea leaves and interpret it in whatever way best fits the individual's/team's biases/agendas.
>> I think that over-reliance on analytics has had a similar effect
I lost track of how many times the directors would tell us, "Since the analytics say A, we should do B." then the research person says, "Sure Jim, great idea, lets get a few rounds of useability research and confirm it first."
Then the always predictable thing happens: Users never align with your analytics. Seeing data and seeing someone struggling to do something basic with your interface is totally different. When directors see these videos, it really makes them see how important research is and not just relying on data to make decisions. Right now, anything the research team wants, they usually get - its had that profound of an impact on our leadership team.
My problem is I can skip all those steps and 8 separate meetings by applying a little common sense to software design.
Unfortunately, orgs often treat devs like this as indulgent or wasting time. They need it to be done the inefficient way because that's the only way they have visibility and control.
Yes. And in most of those meetings where the researcher invalidated the leaders, the leaders have left the meeting saying (and thinking? I’m not sure) they were validated. So because of the leaders we have we should skip the meetings and research in both cases.
Analytics don’t capture the “why” of what they measure, on the user side. Indicators may move in the seemingly right direction for the wrong reasons. Analytics typically can’t tell you what the user wanted to achieve. Knowing the “why” gives a better basis to decide on what changes to try, or to realize what’s actually wrong with the user-facing side of things. Another reason is that they tend to measure an average where in reality there is no average user.
I think the answer to this is roughly ... the content of an applied statistics degree, or a research methodology practicum. There are so, so many ways that quantitative measurement of human phenomena can mislead, from measurement error to conflation between trends/sample sizes/effect sizes, to p-hacking, to good old bias (in interpretation or in deciding what tools to use to smooth or normalize data), and thousands more.
Eg, if you have a bunch of airplanes returning from a war, you might be tempted to armor the areas where they were hit. But you want to armor planes where the holes arent because those are the critical areas.
If you can read literal bullet holes backwards, hundred dimensional preference vectors say something, but we generally have no clue.
I think it's because a lot of analytics are data points oriented instead of being workflow oriented. So you can see that feature A is not being used a lot, but it's very important in a particular flow. Feature B may be used a lot, but it can be only important for a particular class of users while very detrimental mentally for another class.
People use software for a needs, but rarely I've seen a need being highlighted when interpreting analytics data.
Simple example: feature X is rarely used (thus we should get rid of it)
Hold on, why is it rarely used?
Is it hard to use? Is it hard to find? Was it poorly named? Does it work right? Does it get me 80% of the way there? Does it get me 20% of the way there? Do I rarely need it but when I do need it it's a huge time saver? Am I hesitant to depend on it because I fear it will be taken away in a future update?
> Simple example: feature X is rarely used (thus we should get rid of it)
Oh man, I remember a very specific example of this: many years ago now, Google Chrome pushed an update that got rid of the option on the menu bar for "Close Tabs to the Right". I remember looking into the Google issue tracker where people were complaining, and some PM provided a "data-driven" justification: when people opened the context menu, they only clicked on the "Close Tabs to the Right" option 1-2% of the time.
It's a great example of why data without context can give you the wrong answer. Of course the option is used relatively very rarely; you only need to clear out your tabs every once in a while, compared to creating new ones or managing tab groups! But it's still an essential task. It's like saying filing your taxes isn't important because you only need to do it 0.2% days of the year.
I do all the time because the feature exists. I would treat it like a sliding line in my tabs bar. When I'm done with a tab for now it goes to the right, and eventually everything to the right gets closed once I haven't used it in a while
I do. I open a search page, middle click a bunch of links, then want to close all of the ones to the right because I found one that told me what I needed and don't need the rest of them.
It's useful when starting a thread of research of research as new tabs will be opened to the right (Ctrl+Clicking a link). So after it's done, close to the right can be quite useful.
Conversely: Feature X is often used... Because to drive adoption someone made it mandatory for a certain workflow and it nags everyone else so they "engage" with it just enough to make it go away. (Looking at you, "AI" buttons...)
And following this, I'm sure we've all seen the pattern of manufacturing the data required to justify the removal of features. Bury feature → usage numbers tank → oh hey look nobody uses this any more, guess we can safely cut it!
> I think that over-reliance on analytics has had a similar effect;
The over reliance on analytics combine with a lack of metrics and proper accounting.
If you are renting all your infrastructure knowing how people use your app, and what the COSTS of that are is kind of a big deal. If your high dollar client is your lowest margin one, thats a problem that is technical and financial as well as a product insight.
And that infrastructure your renting, it stopped making sense for a lot of orgs to do that almost a decade ago, but here we are where everything is in the cloud because capacity planning is a lost art and was a great throttle on the insanity that the post is describing.
Speaking personally, JVM toolchain bits like Gradle being involved is a turnoff and has kept me away from KMP. Last I checked support wasn't really there yet, but I'd much rather go the other direction and use Swift Package Manager and the associated toolchain on Android.
I work on an open source app that uses a shared swift core for the iOS and android apps and I think it's awesome. I think having all your business logic in swift is great.
At work, we use react native, and although the upgrades and stuff are painful, I'd never give up the ability to ship over the air updates.
> I can absolutely see that being more attractive especially with things like the Duo where, I assume, SwiftUI gives you a number of things "for free".
Apple may not trumpet it as loudly, but these freebies are handed out in UIKit too, for cases where declarative UI is cumbersome.
Generally I've found that while SwiftUI is great for little self-contained bits of UI like table/collection view cells and simplistic template-like apps, it tends to become a bear with complex apps, so it's nice to have both options.
The thing that makes Microsoft's case particularly annoying is that they have demonstrated how they can develop half-decent Electron apps with VS Code, but have simply elected not to with anything that's not VS Code.
Like yes, I'd prefer native and MS can certainly afford to take that path, but they can't even be bothered to make sure that most of their Electron apps land on the upper half of the quality spectrum.
Also they bloated it to death. VSCodium gets you the same solid core app without the oodles and oodles of useless "features" Microsoft has bolted to it.
Yeah, I much prefer the higher PPI and metal chassis of the Kuycon, but its apparently spotty QC and uncertain brand reputation would make me lean towards the BenQ RD280UG if 3:2 aspect ratio were my dealbreaker. It's just too much money to be taking risks with.
I do applaud the company for bringing a new interesting option to the market, though. Integer scaling HiDPI is rare enough (though thankfully is finally becoming more common), but integer scaling HiDPI with a ratio that's not 16:9 is practically a unicorn. If they can get QC under control I wouldn't mind buying from them in the future.
As a dev who regularly works on apps for both platforms, I think one of the main causes for poor support for form factors beyond a standard smartphone on Android boils down to Google refusing to give developers fully fleshed out APIs to support said form factors.
Instead, they just hand you some poorly documented loose parts in a box and tell you, “good luck” and you’re on your own to fill the gaps. Compose is a little better about giving the tools you need than the preceding Android Framework, but it’s still much more “assembly required” and “batteries not included” than the UIKit+SwiftUI world is.
Many iOS apps built using system components will behave 90%+ correctly on the Duo by just compiling against the iOS 27.1 SDK because there are well supported methods of doing things that Apple can leverage to reduce dev work. In contrast, on Android there's 10 ways of doing anything none of which get full-throated support (on top of all the other ways devs invent), and so any time it gains support for a new form factor almost nothing is automatic and it all falls on the devs’ shoulders.
Android actually has one real way to build UIs — it's the views and the resource system. Everything else is just Google's abstractions over that, which are either beta or deprecated.
I'm not sure what kinds of tools do you expect. You do have to make layouts for different screen sizes, no real way around that. You'd usually want two breakpoints, so you have phones, small tablets (and foldable inner screens), and large tablets.
I'd like to see equivalents of UIKit/SwiftUI components that do most of the layout/navigation heavy lifting for you. For most apps, either the iOS 18+ UITabController or UISplitViewController comfortably covers every platform, orientation, and screen an iOS app can possibly run on with a tiny fraction as much boilerplate and manual ratcheting as is required in Compose.
There are, watch the "Strike a pose with adaptive layouts" video they posed yesterday (https://developer.apple.com/iphone-duo/). High level components like split views will adapt automatically, while things like scroll views won't, so there are new adaptive views (AdaptiveView, UIArrangementViewController) to help you move things around.
To be clear, it’s definitely improved some in that time, but there still yet remains plenty of room for further improvement.
Google seems extremely reticent to have anything resembling strong opinions in Android’s API design and so there are still many corners in which well-supported, fully fleshed out “correct” options are absent.
Another reason is hardware fragmentation. An Android developer has to account for over 20,000 unique devices, compared to an Apple developer targeting around 40 supported models at most.
It’s a factor, but the bulk of those devices can be generalized into a handful of categories. Google could also throw around its weight a bit more to get manufacturers to form a consensus on things like how various components are addressed so it doesn’t need to spin its wheels as much on papering over those differences.
Better support for variable form factors wouldn’t force anyone to do anything. It would incentivise them to use that support.
Danox is just saying (IMHO) that Google can’t be bothered because they don’t need Android to be good, they just need it to be good enough to continue existing.
It might, but if you look at other AOSP features in that vein (split-screen multitasking, popout volume sliders, standard dialer app) they're all largely ignored by downstream OEM Android ROMs. I wish that wasn't the case, but it's also clear why this happens.
Google has led many horses to this spring, only to watch Samsung ship some godawful monstrosity and refuse to drink. It's part of Android's identity, not Google's.
"Throw unlimited resources at a development target" has been an established F/OSS embrace/extend tactic for at least 20 years.
Red Hat, systemd, Chrome, Webkit, Android, and a few others come to mind. Others might include Kubernetes, OpenJDK, Clang, React, Docker, Git/Github.
Forks are possible but sustained forks are expensive, and <https://xkcd.com/927/> is always relevant.
It's helpful to note that the guy who literally wrote the textbook on lock-in went on to have a career as Google's chief economist: Hal Varian, Information Rules.
Google lacks the authority to unify folding phone software any better than they can unify homescreen launchers or dialer applications. It's a lost cause. They can spend billions on building the best one ever, and then Motorola or LG will ship a worse proprietary version and never update it. This pattern does not arise from a lack of charity on Google's part.
WindowSizeClasses, Postures, Navigation3, ListDetailScaffolds, the list goes on. Android & Compose is pretty much flawless when it comes to develop for it, it's thoroughly documented and works well.
Layouts will not magically be not dog shit on iOS because Apple put out another version of SwiftUI that you can't use in prod because nobody has the update. 90% of the apps will be stretched. Horizontally. The reality of it is, it's pretty much never worth it to make layouts that are specialised for foldables/tablets.
Also, it's pretty fucking funny to be worshipping Apple like that when they have a single device to support, and then complain about Android that literally had to pave the way and today works on phones that can unfold three times, phones like the galaxy Z Flip that have instead half screens, etc. Apple will tell you they can't back port dynamic islands on last year's release, while latest Compose is happily running on devices from 10 years ago.
> WindowSizeClasses, Postures, Navigation3, ListDetailScaffolds, the list goes on.
Yes, those are the loose parts. They still have to be assembled correctly for everything to work as expected and every app does it a bit differently (there is effectively no endorsed "correct" way to assemble them). This means that Google cannot extend them with new functionality later without breaking some if not most usages of those parts in the future.
Compare that to UITabController in UIKit, which has been present since very early on and got extended recently. If the dev adopts iOS 18 revisions, configuring that single view controller gets you more or less correct presentation and navigation across all sizes and orientations of normal iPhone, iPad, desktop, and now iPhone Duo and implementation is close to identical between apps.
> …and then complain about Android that literally had to pave the way and today works on phones that can unfold three times, phones like the galaxy Z Flip that have instead half screens, etc.
That's fair, but users can't reasonably expect any kind of meaningful adoption of new oddball form factors like that until the platform vendor (Google) rolls out standardized APIs to streamline the process (which Google has partially done, but won't commit to a unified solution for).
> Apple will tell you they can't back port dynamic islands on last year's release, while latest Compose is happily running on devices from 10 years ago.
That is an advantage, but iOS users tend to stay much more up to date so it's something of a moot point. The userbase of versions just three major releases behind is typically below 5% and anything older is fractional at best, so unless you're a Google-scale giant you're probably fine only supporting the newest 2-3 versions of iOS. That's pretty nice since I don't need to keep a drawer full of prehistoric phones running ancient versions of Android to test adequately (so I don't find out about some weird behavior that only occurs under Android 11 in prod)…
You say it's pretty much never worth it to make layouts for foldables/tablets. To be worth it, could mean multiple things. But for the love of perfection, the craft of coding, and of UI design, I think it's totally worth it.
As if hardware companies don't quite famously include spyware in their products. Everything from phones, cars, fridges, TVs, monitors, speakers, light bulbs, laptops and everything else that supports inclusion of spyware.
The thing is, all they really have to do is add an off switch for AI features so they’re not taking up space in the UI and aren’t consuming any extra resources. This toggle should also hide aggressive AI promotions in places like launch screens.
That alone would be enough to make most with a distaste for AI happy. It doesn’t have to be binary, but no, it gets shoved down everybody’s throat whether it’s wanted or not, and that’s how you induce fatigue.
They shouldn't and they won't. That will introduce a new metric -- %user disabling AI, and it will definitely be non-zero, which threatens the "everyone loves AI" narrative, which is the only thing thats floating all the tech-related valuation right now.
How can you be so disconnected from reality? The valuations are based on the immense value of LLMs, which exists regardless of how consumers - who are very much not where the revenue is coming from - feel about it.
I can see how much we are spending on Claude and codex at meta. Believe me, the AI company valuations are not coming from Microsoft word ai assistant.
What immense value? Has it solved world hunger? Has it provided abundant clean energy that no one needs to worry about it? Has it taken care of people's basic needs so that they can be free of work and focus on what's rewarding for them?
Although, some services have started labeling their old natural language processing functionality “AI,” and released additional “AI” features, so an off switch isn’t always possible. The options seem to be to lose previously existing functionality or gain current anti-features.
In their defense “AI” is a pretty nebulous concept.
Really what I want is a “give me 2020 software” toggle. But if we’re wishing, a 2010 toggle would also probably be nice…
> Really what I want is a “give me 2020 software” toggle. But if we’re wishing, a 2010 toggle would also probably be nice…
No kidding. It feels like by some time around 2015 the majority of the commercial software development world gave up entirely on trying to improve value for users. Given the choice, there’s only a handful of software that I wouldn’t prefer the 2010-2015 version of.
That's why for productivity software I vastly prefer open source. Sure it can be janky sometimes but at least I don't feel like I'm being fleeced and sold to the highest bidder.
Speed Download on early OS X releases was a lifesaver back when I was still on 56k dialup. Its multiplexing was the only way I could get decent speeds half the time (browsers would often drift down to single digits) and being able to resume when connections were dropped (at least when servers supported it).
A lot of folks might not want to hear it, but realistically some there's going to have to be a cultural realization that machine-generated low effort slop is not any more desired or helpful than human-generated low effort slop.
That's not an outright rejection of LLM-assisted code, it just means that a real person needs to be awake, at the wheel, and just as significant of a contributor. Literally anybody can point Claude at a repo and say "add X feature" or "fix Y bug" and so PRs that do that carry no value.
The value of a feature or a bugfix is not calculated from the effort required but from the need or desire for said feature or bugfix. So whether or not the barrier to entry has been lowered by llm's is irrelevant. What matters as to it's value is the result.
The important part is the quality of the code, how well-considered its design is, how well it gels with existing code, how readable it is to other humans, how well documented it is, how well its author understands it (and thus, can make surgical changes if needed), and how well it was tested.
A PR that implements a sought out feature or bug fix can be practically worthless if it doesn’t check some percentage of those boxes. The line differs per project naturally, but almost nobody wants a PR that is missing all of them.
That might be true of the raw, unknowable "true" value of the thing, but that's not the same as what people are willing to pay for a thing.
When one evaluates a purchase, implicit in that evaluation is the option to do the work one's self. If the price you are offering a thing is more than the cost of doing it myself, then I will not buy from you.
LLM coding proponents keep saying that it reduces the cost of development to near-zero. We keep hearing about all the "things we wouldn't have done before because it was just too expensive to get people to do it."
If this is true, any day now, the customers and clients and consumers are going to catch wise and start doing it for themselves. I mean, it's been almost a year since LLMs supposedly "10x'd" everyone's productivity. I'm still waiting to see where all this singularity is, so I doubt it actually is true. But it doesn't mean you're going to achieve ungodly margins on your software sales, especially when we're talking about open source software. Value absolutely does have a component that is the cost of the inputs.
The main caveat is that available models are heavily weighted towards “compact” (RAV4 sized) SUVs and larger. There aren’t many little Prius/Fit/Soul type town car models around which is a bit paradoxical with that being the use case that EVs have been well suited to for the longest time.
reply