New EV from Renault and Fiat are below 25K Euro in Europe without subsidies. They are still more expensive than similar sized gasoline cars with manual gear shift, but the difference is small and will pays off in few years.
Gasoline is expensive at the moment because of the Iran war. But as soon as it's done the price of gas will fall markedly and people will forget all about EVs.
EV in China with a reasonable range is already cheaper to manufacture and to buy. Inevitable the same will happen in Europe in the next couple of years. Given the massive improvements in charging infrastructure I do not see why EV would be a default option.
BYD already sells cars that cost less than $10,000 with a 5 star NCAP rating. And there are even cheaper Chinese EVs costing less than $6000 (OK, they're deathtraps but for some people that doesn't matter). And they're not junk either. They work and cut a few corners here an there. Good enough for a lot of price-conscious buyers.
Most importantly: they have LFP batteries which last much longer than Li-ion ones in addition to being safer.
No it's not. If you live in a flat where are you going to charge the thing? Around here there's almost no charging points and the ones that are there are constantly occupied.
I gladly don't own a car but if I did it would be an ICE for sure.
Norway is super rich because of oil money though. Easy to do the right thing for the environment when you are loaded with cash. And most of it gained through fossil fuel exploitation.
In the netherlands it's much harder to upgrade the distribution network, right now in many places it's not even possible anymore to build new housing because the network is full and it will take at least a decade to fix it.
It's not really if you factor in the upgrade of the distribution network. This is what Holland is struggling against (also a result of a really bad decision of 15 years ago on not investing in its upgrade).
That sounds like a solvable problem given a short amount of time.
Two things will likely solve it:
1. There's isn't a fixed number of chargers in the world. Eventually the majority of commercial car parking space will have a charging point because they're getting cheaper and it's an easy value add.
2. Charging is getting ever faster and range is growing. 800v platforms are probably the next obvious step but after that something else will come along.
Imagine an EV with 1000 mile range that charges in 5 minutes and costs less than half what the average ICE car does now. It's far fetched but it's not so far fetched.
There are no such improvements on the way for ICE technology.
Electrification is happening right now in the rest of the world and it can't be stopped because it's better technology.
I doubt it will happen in the short term. The number of chargers isn't really the problem, the energy distribution network is, and that is only increasing with faster chargers.
But I don't want a cheaper car anyway, I want better public transport.
Charging infrastructure for flats is expensive at $4k per parking lot, but the charging infrastructure lasts longer than the car, meaning that the primary problem has nothing to do with money and more to do with the fact that it's an all or nothing proposition where everyone has to get on board simultaneously.
That doesn't count the distribution network for actually getting that energy there. This is the main problem right now. Right now in Holland even people wanting to build a house are blocked because the energy networks are full.
And it's not the only country with that issue.
And charging infra doesn't last longer than the car, standards are still changing a lot, and getting faster charge modes that put more burden on distribution nets.
I mean..that's a problem, but apartment-dwellers are around 20% of Americans, and disproportionately the ones who don't need a car at all, and it's not a problem at all apartments.
Does the ICE marketshare only drop to 10-20%? I feel like that could be describes as "it's over".
A few countries, including Switzerland and Spain, have wealth taxes on a small scale. Several, most recently France, have abandoned them as unworkable.
There exists a simple self-correcting protocol for establishing the value of property: the owner declares the value, and the state reserves the right to buy at that price. Or auction it off. If the owner declines to sell that auction price becomes the new value for computing the wealth tax.
The reason they say "it's unworkable" is because the rich don't want to pay taxes.
That works for real estate, and indeed property taxes are a long running staple of government taxes precisely because land is fixed. Economically, land value taxes are considered the most efficient form of taxation as they have no dead-weight losses, and were championed by Ricardo. But if I have a contract that assigns 10% of the earnings of some mutual fund to a holding company in the Bahamas, then it is not so easy to convince the government of the Bahamas to join you in seizing the asset. The money is overseas, and the wealthy only need to transfer to your jurisdiction whatever they need to spend, which is generally much, much less than what they earn in a given year.
So what happens when you try to tax unrealized capital instead of land is that the former is highly mobile and can arrange to be not subject to your jurisdiction if the rate of taxation is higher than whatever inconvenience is obtained by moving the claims around, so the net result is a loss of overall tax revenue. This is why France abandoned the ISF and replaced it with a tax on land, which is not mobile, and why most jurisdictions have low taxes on capital compared to less mobile things. It's not because it is "fair", but because there are limits to what you can collect that don't apply to things like land or labor.
GCJ was great - I wrote a handset UI entirely in java for a startup in the early 2000's, basically android before android existed, using GCJ. I remember their native interface was somewhat more convenient to use than JNI.
I wish we had GCJ resurrected, now that the java libraries are GPL'd.
That would place significant limitations on the applications that can be compiled. As the JEP explains: “Features such as dynamic class loading, dynamic linkage, dynamic dispatch, and dynamic reflection bring vast expressive power, and have been fundamental to the platform's success. HotSpot handles these features naturally, while static compilers struggle with them. Even heroic amounts of static analysis cannot make up for the fact that these features require many decisions to be made at run time. Implementors of static compilers for Java code have therefore resorted to incompatible constraints, such as closed-world assumptions, and to putting significant burdens on developers, such as having to identify in advance the classes eligible for reflection.”
Therefore I don’t see AOT-only becoming an integral part of standard Java in the foreseeable future.
It works pretty well for greenfield projects on .NET, so long as you can live without third-party libraries that don't support AOT.
Existing code bases can be a pain, though, especially applications that heavily rely on things like C++/CLI and COM Interop that basically need to be rewritten from scratch.
Which is not to say that it's intended to replace the traditional JIT runtime in applications where it isn't troublesome, because it's not.
EF Core and F# still don't fully work, neither do the GUI frameworks, with exception of the buggy WinUI, mostly because it is all COM/WinRT underneath.
EF Core heavily relies on reflection so that's not really a surprise. F# not working surprised me but apparently the main thing is its `printf` depends on reflection.
By "the GUI frameworks" I assume you mean Microsoft's GUI frameworks. They're all basically abandoned or just bad. Use Avalonia! It's better, cross-platform, and supports AOT!
Well, they had enough time to refactor EF Core to use code generators.
F# is improving on .NET 11, but still not fully there, as contrary to the rest of .NET, it is mostly community driven.
Most Microsoft shops only consider Microsoft GUI frameworks, regardless of the great work done by Avalonia, and Uno as well.
As for being bad, they surely are much better than most competitors from other ecosystems, unless we're adding Delphi, C++ Builder, Qt into the picture.
I had projects with Java on the server and Microsoft GUIs on the desktop, for example. Swing and JavaFX are also quite good, however require additional programming for what Forms and WPF do out of the box, unless one is willing to pay for something like JGoodies.
we are not talking about fully supporting dynamic loading, because it's not needed in all the cases, and in some cases, the list of allowed classes in the application can (or must) be limited.
i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++.
> i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++.
What is the objective here? Startup latency or throughput? Both will be vastly improved by JEP 544.
If you haven't checked it out yet, GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution. You have to do some configuration to deal with reflection and dynamic class loading since there's no JVM in the produced build, but it comes with tooling to simplify that. And that restriction is being addressed by Project Crema [2].
The slight drawback is that AOT compiled Java code's performance isn't as good as the JIT compiled form running on the JVM.
There's a reason why folks keep coming back to JIT compilation. It's hard to beat the value that can be gained from actually gathering data on how the code is actually used, which leads to a whole set of potential optimisations (which is the problem Profile Guided Optimisation attempts to solve for AOT compiled code.) The JVM is arguably one of the most advanced and capable JITing runtimes.
As with anything it's a trade off. Fast start times, pretty fast running (I think maybe less memory usage?); vs the full JIT speed you can get on the JVM at the cost of start-up speed and memory consumption. All depends on what you want to use the application for.
If you're talking something like a serverless function, go native. If you're talking production server where you're measuring runtime in more than dozens of minutes, probably better to stick to the JVM & JIT.
Full agreement with everything you said. Just one detail to add on serverless (and potentially in a scheduled environment like k8s), startup time can be an order of magnitude or more faster in a native build. For instance, I have some quarkus applications that can take 10 seconds to ready running via the jre that take 10ms or less to start as a graalvm built binary.
Java has many dynamic features where runtime optimization is required to remove the overhead. Virtual method calls are opt-out instead of opt-in, and there is an open world assumption. The possibility of doing stack allocation of objects depends on the call hierarchy (in the future it will get a bit easier with value objects). Also, C/C++ are not managed languages, therefore the effects of bad optimization don't hurt as much.
That won't be necessary when 544 lands. The only thing you'd gain is not having to ship the JIT compilers in a jlink build. Also, I'm fairly certain that the JIT compilers can be turned off with some combination of runtime flags to ensure only the AOT generated code is executed.
reply