I think charging speed is the #1 stat to look for in an EV.
There isn't going to be an EV with a range long enough for an entire road trip, but OTOH with recharging EVs have an infinite range. People don't care about range of their ICE cars, because they can fill up quickly. The same applies to BEVs — with fast charging, it's just a quick stop for a coffee, and it doesn't add to the trip.
Charging speed also matters for people who can't charge at home. Having to charge for 20 minutes once a week is not a big deal, especially if that can be combined with a shopping trip.
As long as the charging stop is less than what you’d stop for anyway then it doesn’t really matter, but there is the issue of charger availability so shorter times would benefit this.
Electric car sales are still growing large amounts year on year so this puts pressure on existing charging networks. When I stopped at a regular stop the other week there were multiple new cars in the charging bays. Still lots of spaces but they need to start making more chargers to keep up with increasing demand.
> I think charging speed is the #1 stat to look for in an EV.
I think it's the #1 stat to look at if you can't charge where you park, you drive a lot during the week, or you actually need that long range for road trips.
But not integrity of the program itself. You can still have data loss and garbage results.
I really like the borrow checker and Rust's Send/Sync thread-safety markers, because they nudge towards cleaner thread-safe architecture, and give compile-time guarantees that work even across complex code, all kinds of collections, and 3rd party dependencies.
Java only promises to protect integrity of JVM itself, not your data. If you accidentally write to a non-concurrent collection from multiple threads, it's not a program-corrupting Undefined Behavior like in C/C++/golang, but it can still misbehave by corrupting the collection itself, causing it to mangle or lose data, or in the best case throw an exception. Either way you don't get the intended program behavior, and you may be unaware of using a wrong collection type until you create an invalid access at compile time.
This is different from Rust, where thread-safety is part of the type system, so multi-threaded code that could write to a shared HashMap instead of a ConcurrentHashMap just won't compile with a type error.
The distinction they might be going for is the difference between guarantees and helpful utilities; good utilities can provide guarantees, but there's a lot to be said for default-safe and a safety culture
It's a shame this is used as an excuse to keep the heavy ICE SUVs and trucks. There are many EVs lighter than an average pickup truck.
If people really cared about this, they'd demand train-based public transport instead (no tires! fully electric! self-driving too!), or at very least limits on car weight regardless of the engine.
Trains also have brakes which produce large quantities of fine particles.
This is especially a problem in enclosed spaces with limited ventilation: on parts of the London Underground, air pollution in the tunnels can be many times worse than on the streets above.
Trains are also way more efficient than cars at transporting people. If everyone taking the train was driving instead you can bet air quality would be way worse.
Why do you think that was an excuse for ICE vehicles? That’s your own biases showing. I’m anti-car in general, and very pro public transit.
EVs aren’t going to be the savior of climate change. They do some things better than ICE cars, but do some things worse. Denying those worse things is just putting your fingers in your ears.
Unfortunately buses and trains are only viable above a certain density, and many communities exist configured in such a way that they are intentionally low density. While metal mining might have an environmental impact, abandoning millions of existing homes and building new ones in cities not only also has a large environmental impact (concrete also isn't great for the environment), but it is also politically, economically, and practically unviable.
A mix of solutions will be needed to fix the variety of different and unique problems that exist.
Busses are viable as long as you make them viable. If you have a busstation at a 1 km distance you can make it viable in most places even with the mega sprawl of the US. The economical incentives of a car economy is perverse it is the tradgedy of the commons distilled.
Most of the US has single digit numbers of people per square km. And the average daily commute is 61 km. And suburban sprawl had led to the decline in city centers. Low density, high distance, and poor directionality are very significant challenges for planning a bus line.
Have you used bus systems in the US? Even in cities that have made a large investment in bus service, it can be a challenge.
I know it sucks living in the US without a car, I do think it is important to know that it can be done. You are going to have to prioritize though. I've lived carless in some of the most car dependent places of the earth, including the US so I know what makes that a great deal.
I closely know people who have lived in extreme rural areas of the US without a car. You are right that it is possible. But it certainly presented significant challenges. There's a reason why people buy cars in the US.
I personally loved taking busses and trains when I lived in the city. I didn't go far but with a pass I'd take them all the time. I now live in a suburban sprawl and I can never convince my wife to bus it. She usually has a point: it's pretty inconvenient to get from our home to a bus/train stop. I live by a train but would love it if they were electric though that'd do nothing to reduce brake dust.
They're ugly but I'd love them if I had them. Why the hate for hydrogen? Mark my words, we're being forced to upgrade our HVAC systems to be "green" the use TONS of electricity when in 20-40 years, we're going to do it all over again to move on to hydrogen. I'm already spending $300 a month on electricity using "green" tech. The second I can produce my own hydrogen, I will.
Majority don't buy their electricity from green suppliers and don't care where their batteries come from. Cobalt mines are hell. Either way, I stand by what I said. Spending 40k+ on a 10 year product that will cost 20k+ to refurbish isn't green. My 12 yo EV battery cost more than the car to replace.
In some places it’s fairly hard to get power that isn’t generated by renewables. In New Zealand the grid is 80%+ renewable and my supplier is 100% renewable.
In IL there are no green providers but 3rd parties provide it somehow from TX. I'm not sure how it works but it's quite expensive. I did it for a few years but stopped. Now, with my increase in energy usage due to moving away from gas, it's hard to justify. In the United States, we want to move everything to electric and I believe that's a mistake. Not without nuclear power to subsidize costs. I'd imagine my monthly costs would be closer to $400, which I believe to be insane.
This is by mass, which is a weasel metric that discounts all gaseous emissions, and the smallest particulates that stay in the air.
Impact on health is not linearly proportional to the mass.
It's almost the opposite - the smallest particles can linger in the air and get absorbed.
You could eat a chunk of a tire without a significant health effect, but breathing the same mass of almost any gas would kill you.
The CVE/CVSS system lacks ability to deal with soundness issues.
If the language or a library promises to catch a mistake, and it doesn’t, that’s not automatically exploitable unless the programmer has actually made that mistake. If there wasn’t a promise in the first place, there would be nothing to report.
Unfortunately, CVE can’t see the difference between reporting a bug, or reporting a theoretical possibility of having a bug that never actually happened.
Frankly, I don't think industry is going to allow soundness issues to ever achieve parity of importance with what we think of as CVEs. There's simply too much code and mindshare around languages that don't worry as much about soundness.
I'm not saying it is right, just that concerns around soundness will likely be hand-waved away. And it is to everyone's detriment.
Once you know Rust, the borrow checker is not impacting your productivity.
This leaves you with a fast language, with robust and relatively easy multithreading, and a rich ecosystem of high quality libraries. I don’t know any other AOT language that can come close to such productivity. The closest may be golang, but it’s not ideal for parsing.
AFAIK no other language has this kind of thread safety in the type system, enforced at compile time. The next best thing is having a particular share-nothing or message-passing paradigm built into the language.
Golang for example does not enforce use of synchronization when mutating shared objects from multiple threads, even though it can lead to crashes and vulnerabilities, just like in C and C++.
It may be hard to appreciate Rust's fearless concurrency until you see for yourself how it can save you from heisenbugs. You can invoke any function, which could be even a 3d party dependency using more dependencies and touching a million lines of code, and Rust will tell you right away if any of that code has some thread-unsafe behavior (e.g. some method may have internal cache without proper locking). With the safety net of the borrow checker you can use constructs that would have been considered irresponsibly dangerous in other languages, like spawning threads referencing on-stack values of other threads.
>"It may be hard to appreciate Rust's fearless concurrency until you see for yourself how it can save you from heisenbugs."
Writing multithreaded native applications is my bread and butter. Including enterprise grade application servers with multiple clients and various IT systems accessing it. I can't recall when was the last time I had any problems caused by improperly mutating data.
Mozilla, a project full of C++ experts, tried to write a parallel CSS engine in C++ twice. They couldn't get it working either time. But their first attempt at using Rust worked out -- even though many of the devs working on it were completely new to Rust.
>"Mozilla, a project full of C++ experts, tried to write a parallel CSS engine in C++ twice. They couldn't get it working either time."
The fact that Mozilla can not do a particular thing in particular way has zero value for others not in the same boat. I am not Mozilla. Do not know their problems and do not care. Maybe parallel CSS is too complex by nature. I can only relate to my own situation. My commercially deployed systems work and serve bazillion of clients with no problems.
What weight do you assign Mozilla's data point? It isn't rational to say zero, is it? Also consider that Chromium still doesn't have a parallel CSS engine -- my understanding is that they tried and failed as well.
I've also written systems in Rust, some embarrassingly parallel and some that are more complex than that. The embarrassingly parallel ones never took more than 10 minutes of effort to do. The more complex ones are harder but still possible.
I agree that your data point should also be assigned non-zero weight.
It is well above zero. But this is for very specific situation - parallel CSS.
I on the other hand had never had problem managing / mutating state in my multithreaded programs. I did have one situation with deadlock when interacting with Directshow signal processing. That was around 2002 I think. Took me one day to analyze and fix the code after the bug was reported. But Directshow is an incredibly complex piece with some weird behaviors. Other then that I do not recall any real problems. Btw that particular software was desktop application and written in Delphi, not even C++.
So yes to me the opinion of Mozilla's team is totally irrelevant. It is of course totally mutual but I suspect that my situation - C++ application servers is way more common than parallel CSS.
Upload is usually slower, more latency sensitive, and suffers from tcp cold start. Pages also make lots of small requests, so header overhead can add up.
HTTP/2 added header compression for these reasons.
For a while Apple existed for Steve to make products he’s proud of.
I have a very deep resentment for the App Store, because that was a turning point towards controlling the platform, and start of a feudal relationship with developers.
They’ve went from (half-assed) open source efforts to outright banning GPL completely. They’ve went from trying to use open protocols to putting DRM throughout entire stack on everything they could.
Apple has been high margin company with expensive products, but arguably worth the cost if you appreciated their style and attention to detail. But the OS and services side has shifted to just extracting as much money as they can, because they can. Their 27% cut on purchases made outside of iOS is just pure greed and spite.
There isn't going to be an EV with a range long enough for an entire road trip, but OTOH with recharging EVs have an infinite range. People don't care about range of their ICE cars, because they can fill up quickly. The same applies to BEVs — with fast charging, it's just a quick stop for a coffee, and it doesn't add to the trip.
Charging speed also matters for people who can't charge at home. Having to charge for 20 minutes once a week is not a big deal, especially if that can be combined with a shopping trip.