Which is ~enough to cover the vast majority of commutes, and the majority of US commutes.
Keep in mind that even if 20% of your commute is done on petrol, the other 80% isn't.
---
[1] Yes, there are PHEVs with shorter ranges, but those tend to be weird luxury models that for some compliance reason have a battery strapped to them.
That data needs to be split out by how the person acquired their PHEV. In much of Europe the majority of PHEVs are purchased by companies because of tax incentives. I remember seeing a study which said that people who are driving a PHEV because it was assigned to them by their employer are much less likely to plug it in than are ordinary consumers who bought or leased a PHEV.
Does it? It’s a million cars sampled at random. Perhaps fleet affects that a little, but these are big numbers. Claimed 80% reduction in emissions, real world 20%. Some fleet skew is not going to impact that meaningfully
> In much of Europe the majority of PHEVs are purchased by companies because of tax incentives.
Love to see some evidence for that being the majority
In Portugal a whopping 87% of PHEV registrations are to corporations [1]. It was close to 60% in the UK a few years ago [2].
This should not be too surprising, once you learn another fact that is probably more surprising: corporate sales make up a majority of car sales in much of Europe. Around 65% in Germany, 60% in UK, 55% in France (the 3 largest car markets in Europe).
Corporate buyers love PHEVs. They get many of the same or similar tax breaks that full EVs get, whereas hybrids that are not PHEVs usually just get the same corporate tax treatment that ICE cars get. Even though a PHEV usually costs more upfront than a similar regular hybrid which usually costs more than a similar pure ICE, the tax breaks make the PHEV a better deal even if the company has no intention of ever plugging it in.
Compare to individual buyers. They get much fewer incentives from the government. For them the higher cost of a PHEV over a regular hybrid only makes sense if they are going to plug the thing in.
Countries are starting to phase out the PHEV tax breaks for corporations, so we should start seeing the percent of PHEVs that actually get plugged in start to go up.
Although outliers like Portugal are interesting, the whole EU averages are more useful.
you are right in that corporate sales make up ~60% of new car registrations eu wide, that is kinda crazy.
But 11.7% of EU corporate registrations are PHEV [1] versus 9.8% overall [2]. So, it’s a little higher, but not really meaningfully higher.
So yeah, ~61% of new PHEVs registered to corporations. But I’m assuming a majority of those corporate cars get resold after a few years , entering the private registered market. So I don’t really know how to guess at the % of corporate ownership of cars currently on the road. Let’s wildly guess that half of new car reg corporate PHEVs are in private hands now.
That leaves ~33% of total PHEVs corporate owned, which is a sizable chunk and would affect the statistics somewhat, if those folk truly have different behavior.
Btw this analysis of the whole situation has a ton more data than the guardian I originally linked [3]. A huge part of the problem is even in full electric mode the PHEVs still used gas 1/3rd of the time due to weak ev engines. So even if plugged in they’re still a lie in real world emissions.
So I doubt changing the corporate ownership % will change the results that much, but we’ll see.
The biggest change to watch for will actually be once the UF (utility factor) for EU PHEVs is adjusted down in 2027 to match the real world emissions [3]. If they do that, I expect the category to collapse in sales as it won’t make sense for manufacturers to subsidize them as an emissions loophole anymore.
You'd be surprised! Thesis-driven investors exclusively monitor specific areas looking for edge. I've already met with groups like Cargill who approached me while still in Shenzhen. They really are ear to the ground.
Very interesting. I would not have expected my home, Spain, to fail at fish and starch. Living in northern Spain where fishing and potato farming are big business gives one a warped perspective apparently.
> Unfortunately they’re bad at math and chose the wrong trade-offs
They chose the exact same tradeoffs as C++'s async/await (and the same overall model as Python/NodeJS), so I'm not sure what that says about programming as a whole.
Async in Rust and C++ is nothing like it is in Python or NodeJS. Choose your own runtime is a very different model than having a default one.
Not to mention Tokio (most popular runtime for Rust) is multi-threaded by default. So you have to deal with multithreading bugs as well as normal async ones. That is not the case with most async languages. For example both Python and NodeJS use a single thread to execute async code.
> Async in Rust and C++ is nothing like it is in Python or NodeJS. Choose your own runtime is a very different model than having a default one.
Python still has pluggable eventloops - this is sort of mandatory to interact with weird things like GUI toolkits, and Python's standard event loop was standardised pretty late in the game. Early on there was even an ecosystem split between Twisted and competing event loops implementations.
> For example both Python and NodeJS use a single thread to execute async code
I'd argue this is more a historical artefact of how the languages functioned before futures were introduced, rather than an inherent limitation.
It is an inherent limitation. Multithreading is not free after all. One of the big pros of async programming is the concurrency you get within a single thread. When you make the async runtime multithreaded by default (like Tokio) you don't get this advantage anymore.
You can put tokio in single-threaded mode if you prefer - it's an explicit performance tradeoff. The multithreaded work-stealing executor has higher throughput at the expense of needing more synchronisation.
Or you can schedule your thread-local tasks in a LocalSet to run them all on the owning thread, while keeping the other threads around to handle tasks that are intentionally parallel.
The general theme here is that tokio (and C++ equivalents) provide you the flexibility to do more things than the native Python/Node runtime does (and yes, the defaults take advantage of this). But the underlying intention is the same (and post-GIL we expect to see some movement in this direction on the Python front as well).
For problems that aren't overly concerned with performance/memory, yes. You should probably reach for threads as a default, unless you know a priori that your problem is not in this common bucket.
Unfortunately there is quite a lot of bookkeeping overhead in the kernel for threads, and context switches are fairly expensive, so in a number of high performance scenarios we may not be able to afford kernel threading
In that sentence I’m referring to the abstract idea of a thread of execution as a model of programming, not OS threads. A green thread implementation could do it too.
But what you said about kernel implementation is true. But are we really saying that the primary motivation for async/await is performance? How many programmers would give that answer? How many programs are actually hitting that bottleneck?
Doesn’t that buck the trend of every other language development in the past 20 years, emphasizing correctness and expressively over raw performance?
> But are we really saying that the primary motivation for async/await is performance?
Of course - what else would it be? The whole async trend started because moving away from each http request spawning (or being bound to) an OS thread gave quite extreme improvements in requests/second metrics, didn't it?
I agree. Managing many http requests or responses was a motivating problem.
What I question is whether 1. Most programs resemble that, so that they make it an invasive feature of every general purpose language. 2. Whether programmers are making a conscious choice because they ruled out the perf overhead of the simpler model we have by default.
That is why we have the function colouring problem and a split ecosystem in the first place - if it were obviously better in all cases, we'd make async the default, and get rid of the split altogether (and there are languages, like Erlang, that fall on this side of the fence)
> But are we really saying that the primary motivation for async/await is performance?
The original motivation for not using OS threads was indeed performance. Async/await is mostly syntax sugar to fix some of the ergonomic problems of writing continuation-based code (Rust more or less skipped the intermediate "callback hell" with futures that Javascript/Python et al suffered through).
Python used multiple threads to handle I/O long before async/await was a glimmer in anyone's mind (despite the GIL). nodejs is one of the very few languages I can think of that was born single-threaded and used an asynchronous runtime from the get-go
Importantly though, performance might be worse depending on use case and program. Specifically with scheduling in user space it can negatively impact branch prediction as your CPU is already hyper optimized for doing things differently.
It's all nuanced and what to choose requires careful evaluation.
If the expected Linux experience is "go build your own if you disagree", then I'm not clear how that is any better than being told the same by Microsoft/Apple
It's better because at least you can. With windows and apple you have to live with it. But that's not the expected experience. UX in Linux has only become better with time, all things considered.
There are alternatives to Wayland, Systemd, Vulkan, etc. on Linux. There are far fewer options on macOS and Windows, "build your own" typically entails starting from scratch.
Is is Mercedes-Benz deciding to bring back buttons, or is it that the EU's NCAP safety rating mandated that they bring back buttons, and they are spinning it as a voluntary decision?
reply