It’s range anxiety and it’s real. And it’s not entirely unjustified. Where I live in the Midwest I have literally never seen a public charging station. I know they exist because I can search for them on maps app and I see dots, but it speaks to their general small numbers that I’ve never seen one in person that I can remember.
Now, prior to this, I lived in California for many years from 2011 until 2019, and I saw tons of EV charging stations there. I left with the impression of “wow, charging stations are everywhere”, and that was 7 years ago.
But now in my Midwest metro area, I can honestly say there are zero that I can think of within a 10 mile radius of my house. Not one. (They’re out there somewhere, but they gotta be tucked away because I never notice them enough to remember them.)
It’s no small wonder that all my friends from California drive electric cars, and all my friends from this area (near my childhood home, so I know lots of people) think EV owners are crazy. [0]
If EV charging stations were visibly everywhere and charged in 5 minutes I could say without a doubt that every one of them would be swayed. So I don’t think they’re being irrational at all.
- [0] It is common to go on long road trips here, since the weather sucks, and people really don’t want to rent a car to do it. Plus a ton of people tow shit. Half my friends have campers and the other half have boats.
Most current EV owners charge at home for daily needs, you really only need charging stations for long distance and owners w/o options where they park (i.e. renters or street parking only) Even with street parking, I see lots of people running cables across the sidewalk (with safety / step covers thankfully)
I drove across the country and accounted for midwest charging. Generally the rocky mountain states are minimal, but I was not without a charger ever 30-40 minutes of travel time through the midwest. Most of them are either in Big Store parking lots or at gas stations like Casey's. You need far fewer of them than gas stations, so we should expect to see fewer of these vehicle refill stations in the future anyway
Yep. Mine is always charged at home, and so I've never needed to use a charging station locally. They're around just by virtue of the area being part of a major metro, but I haven't needed them.
I haven't yet done a cross-country drive but would like to and have plotted out routes with ABRP, and yes, there's more in the midwest states than you'd think. Enough that just about any EV with EPA 250mi range or better can manage a long haul trip without too much trouble (just with a few more bathroom/snack/coffee stops).
yup ABRP was awesome for the trip, nothing out there comes close
Be warned, as you approach and cross the Rockies, there is a lot of uphill and wind. Didn't mention this, but I also did the trip in early March, temps were just above freezing most of the trip, range was terrible. There's a spot in NE, which I'll never forget. Only stop in the middle of a long gap in stations, steepest incline in NE, blew through most a charge in 90 miles. Then the charger is old and very low charge rate (like 5+ year old speeds). The saving graces are (1) public restroom (2) Awesome awesome coffee shop owner who made me a nice brew after hours when I asked him where I might find one as we passed on the sidewalk.
WY was worse on the charger infra, most unreliable and sketchy part of the trip (mostly because of snow in the mountains as temps dropped below freezing, but also the worst charging infra at any point)
Yeah, if/when the trip happens it'll probably be during the warmer months just to keep things simple, and the west → east half of the loop will probably be on I-40 which shouldn't pose too many problems.
Yes, I think people mistakenly believe that if chargers aren't as ubiquitous as gas stations, there must not be enough of them. Range anxiety can still happen on a cross country trip, but not for the vast majority of daily driving. Now, if you live in an apartment building where it's difficult to charge at home, it's a different story. Not so much because of range anxiety, but because the cost of public fast charging rivals and sometimes exceeds the cost of gasoline.
I'm in California, and cost per mile of electricity vs gasoline is pretty similar in a Gen 1 Chevy Volt.
I get 35 miles per gallon. That's also how for I can go on 10kwh in the good conditions.
If gasoline is below $4.50 a gallon, it's cheaper to just run the volt on gasoline than it is to charge it at home.
I suspect that the causation runs the other way. They think EV owners, Californians, and anyone who doesn't smell like petroleum is crazy. Therefore they won't buy electric cars and so nobody builds charging stations.
I can only speak for the people I know well (I know people from lots of different backgrounds here), but I can confidently say that every one of them would love EVs if charging stations were everywhere and charged in 10 minutes.
There may be a real chicken-and-egg problem with building the charging stations, but if it were magically fixed and ultra fast charging stations were ubiquitous overnight, I think minds would change overnight as well. It’s just nobody has the motivation to take the financial hit to build them and jump-start things.
My point being that they’re not irrational, and it’s not EV hatred that is driving it.
The biggest issue is that people think EV's are gas cars that have electricity instead of gasoline, with the main difference being you have to sit at the "gas pump" for 45 minutes instead of 2.
But the way you daily an EV is totally different than a gas car, and even the way you travel is totally different. People have no concept of EV ownership, so they just go with the gas model that they know. But it is totally incorrect.
> The biggest issue is that people think EV's are gas cars that have electricity instead of gasoline, with the main difference being you have to sit at the "gas pump" for 45 minutes instead of 2.
If you don’t live in a conventional house with access to overnight charging, this is exactly what EV’s are. But we keep talking down to people like this, as if every non-EV owner must just be stupid or something.
We're not speaking down to people like that, we are telling them they are not part of the conversation. You really shouldn't get an EV if you cannot plug in overnight.
> I can confidently say that every one of them would love EVs if [...]
And I can confidently say I see rural pickup owners rolling coal about weekly, so no, they will not be loving EVs, because it hampers them destroying their surroundings.
As I said, I am only talking about people I know personally. Not everyone is like that, please stop lumping everyone together.
Not everyone who dislikes EV’s is doing so irrationally. Not every one of them is a moronic anti-environmentalist. Most people are just trying to get by and they’re looking at what they think is best for them. Thinking everyone who disagrees with you must be a backwards coal-rolling moron is… not a great approach. You can do better.
I cannot understand “rolling coal” at all. I’d love to know more about the psychology of this and what makes it so attractive that you actually spend money and time to do so.
With my plugin hybrid I have currently the best of both worlds. The 2x25km commuting is electric, and longer weekend drives are gas. And being in Europe, I am not worried about charging stations for whenever I'll switch to full electric - I enjoy taking gas station breaks. I know it's only one data point, but it's my data point :)
It matters what the tongue and voice box are doing in the surrounding sounds. The next letter (t) is voiced, and the prior sound is a vowel, so in practice many English speakers will continue to “voice” the c sound between e and d, the “g” is just a voiced “c”, which makes them homonyms in most speakers.
(This post brought to you by YouTube, who keep putting Dr Geoff Lindsey in my recommendation queue, and now I’ve become a part time linguistics enthusiast. Other interesting facts: “chr” and “tr” are also almost entirely homonyms in most speakers. Try saying “trooper” and “chrooper” and see what I mean. In fact my 4 year old, who is recently learning to write, drew a picture of a truck and wrote “chruck” on the paper.)
> By giving all of your hosts dns names you don’t have to care about the individual addresses much. If they change just update the dns zone
"just" update the zone? Yikes. I prefer to not take that downtime in the first place. (And I know from experience, I've written hooks for dhcpcd that automatically reconfigure my zone file, firewall rules, rad.conf, etc, if I get a new network prefix! But I don't pretend that this is a workable approach for everyone.)
> The second is to configure a Unique Local Address for each host using SLAAC
Yes, this is the way. Where you used to use RFC1918 addresses, just use ULA. It's simple and fits the mental model you used to have with IPv4. You don't even need NAT, just give both the GUA and ULA addresses to each host, and use the ULA everywhere you want LAN-like semantics.
> as long as [...] (S|D)NAT are not first class citizen in IPV6 Standards and Implementation
Yeah, I mostly agree... IMO, a ULA (equivalent to RFC1918, so 192.168.x.x and so forth) is the only sane way to set up your IPv6 network at home, unless you're one of the wizards who owns their own prefix. Dynamic prefix delegation just breaks too many things when the prefix changes, and I really wish NPTv6 was more supported and ubiquitous, because it solves the problem in the most elegant way IMO.
> there's no mapping of the IPv4 Adresspace into the v6 space
You don't need NPTv6 to use ULA. Just use both ULA and the dynamic prefix from your ISP. The latter is handled automatically by DHCPv6-PD, and if you're only using it for outbound connections then it changing isn't going to break anything.
I'd say this is actually elegant, compared to NPTv6 which is a kludge and will break things (and isn't well-supported anyway).
I definitely do both ULA and GUA at home, but this only really works well to the degree that the OS will prefer the ULA when connecting to things. Like if I want to put hostnames in netgroups, I need reverse DNS to work (which only works if the client is using the ULA address I expect.) In fact the whole idea of reverse lookups working and having expected hostnames show up where you want them to (logs, etc) really depends on not only using ULA for connections, but using the stable address and not the privacy address, which can also cause issues.
For the most part it works today, if I stick to using ULA’s only in my zone file, and configure hosts to prefer the DHCPv6-provided ULA for connections in the ULA subnet, it’s fine. But suddenly if you connect to somehost.local instead of somehost.fqdn, the machine picks a GUA source address and you’re back to being unpredictable.
So although I say I want to use NPTv6 and be ULA-only, I don’t actually do that today, so I’m not super familiar with the downsides to the approach. But it does sound a lot cleaner to me in theory.
> if you're only using it for outbound connections then it changing isn't going to break anything.
A prefix change absolutely does break things in a lot of setups though. It happens something like:
- Your router reboots unexpectedly (no time to rescind the RA)
- Router comes up and gets a new prefix, starts advertising it
- Clients are brain dead and continue using the old prefix when making outbound connections.
I’ve had this happen and both Apple devices and Linux devices (I had no Windows machines) kept using the old prefix until I went around and rebooted them. So connecting to any IPv6 WAN address would fail, and only IPv4 was saving me from my internet being down until I went and manually rebooted everything.
There have since been RFC’s that come up with recommendations for routers to keep a stateful log of old prefixes, so that they can rescind them (advertise a zero TTL) when a new prefix arrives… but afaict none of them actually do this.
My prediction [0]: It will take roughly 100 years for IPv6 to be ubiquitous enough to shut off IPv4. That's not intended as hyperbole, if anything it's an understatement.
Because, it's not going away: You can talk all you want about how IPv6 should have been a more straightforward expansion of the address size, but this is all in the rear-view mirror at this point. IPv6 is going to be with us forever, you may as well get used to it. It's already everywhere in 5G deployments, ISP's like Comcast use it for 100% of their out-of-band management, China is making huge progress moving to it as part of their 5-year plan, India is progressing nicely in their transition, the list goes on. We're already way too far along in the transition to abandon it in favor of something else.
But it's not going to happen any quicker than we've seen, either: There's no urgency (no "must-have" use case) except for what organizations are imposing on themselves. Yeah, IPv4 addresses are more expensive, but you don't really need many of them as a business (you can get by with a small handful of public ones, and just using L7 load balancers and SNI for everything) nor as an ISP (CGNAT can get you a long way.)
So we have a situation where things are migrating very slowly, mainly only in places where it makes sense (mobile deployments, home ISP's where the users don't actually administer the network), and generally mostly for new deployments. This is a recipe for IPv4 to be around for a very, very long time. We're used to technology moving at breakneck pace, but that's only the case for the higher-level stuff. The core infrastructure like the internet protocol is likely the textbook example of slow-and-steady, and a case where it's actually not crazy to think of centuries-long timeframes for things.
[0] Barring any unforeseen black-swan events like a world war destroying all technology and having to rebuild from scratch or something. Or a competent international agreement to aggressively migrate to it (I don't know which is more likely.)
> If you can add safety very carefully on top of unsafe stuff (without any help from compiler), why not just use `c` and add safety by just being very careful?
Y'know people complain a lot about Rust zealots and how they come into discussions and irrationally talk about how Rust's safety is our lord and savior and can eliminate all bugs or whatever...
But your take (and every one like it) is one of the weakest I've heard as a retort.
At the end of the day "adding safety very carefully atop of unsafe stuff" is the entire point of abstractions in software. We're just flipping bits at the end of the day. Abstractions must do unsafe things in order to expose safe wrappers. In fact that's literally the whole point of abstractions in the first place: They allow you to solve one problem at a time, so you can ignore details when solving higher level problems.
"Hiding a raw pointer behind safe array-like semantics" is the whole point of a vector, for instance. You literally can't implement one without being able to do unsafe pointer dereferencing somewhere. What would satisfy your requirement for not doing unsafe stuff in the implementation? Even if you built a vector into the compiler, it's still ultimately emitting "unsafe" code in order to implement the safe boundary.
If you want user-defined types that expose things with safe interfaces, they have to be implemented somehow.
As for why this is qualitatively different from "why not just use c", it's because unsafety is something you have to opt into in rust, and isn't something you can just do by accident. I've been developing in rust every day at $dayjob for ~2 years now and I've never needed to type the unsafe keyword outside of a toy project I made that FFI'd to GTK APIs. I've never "accidentally" done something unsafe (using Rust's definition of it.)
It's an enormous difference to something like C, where simply copying a string is so rife with danger you have a dozen different strcpy-like functions each of which have their own footguns and have caused countless overflow bugs: https://man.archlinux.org/man/string_copying.7.en
1. In `c` one have to remember a few, fairly intutive things, and enforce them without fail.
2. In rust, one have to learn, remember ever increasing number of things and constantly deal with non-intutive borrow-checker shenanigans that can hit your project at any point of the development forcing you to re-architecture your project, despite doing everything to ensure "safety". But the borrow-checker can't be convinced.
I have had enough of 2. I might use rust if I want to build a critical system with careless programmers, but who would do such a thing? For open source dependencies, one will have to go by community vouching or auditing themselves. Can't count something to be "Safe" just because it is in rust, right? So what is the point. I just don't see it. I mean, if you look a bit deeper, It just does not make any sense.
What is the point. If I share something, someone is going to come along and say. That is not how you are "supposed" to do it in rust.
And that is exactly my point. You need to learn a zillion rust specific patterns for doing every little thing to work around the borrow-checker and would be kind of unable to come up with your own designs with trade-offs that you choose.
And that becomes very mechanical and hence boring. I get that it would be safe.
So yes, if I am doing brain surgery, I would use tools that prevent me from making quick arbitrary movements. But for everything else a glove would do.
To learn something is generally the point. Either me, or you. I’ve been developing in rust for half a decade now and genuinely do not know what you were talking about here. I haven’t experienced it.
So either there are pain points that I’m not familiar with (which I’m totally open to), or you might be mistaken about how rust works. Either way, one or both of us might learn something today.
All lessons are not equally valuable. Seemingly arbitrary reasoning for some borrow checker behavior is not interesting enough for me to learn.
In the past, I would come across something and would lookup and the reasoning for it often would be "What if another thread do blah blah balh", but my program is single threaded.
Borrow checker issues do not require multiple threads or async execution to be realized. For example, a common error in C++ is to take a reference/interator into vector, then append/push onto the end of that vector, then access the original error. If that causes reallocation, the reference is no longer valid and this is UB. Rust catches this because append requires a mutable reference, and the borrow checker ensures there are no other outstanding references (read only or mutable) before taking the &mut self reference for appending.
This is generally my experience with Rust: write something the way I would in C++, get frustrated at borrow checker errors, then look into it and learn my C++ code has hidden bugs all these years, and appreciate the rust compiler’s complaints.
>If that causes reallocation, the reference is no longer valid
Doesn't the append/push function return a pointer in that case? At least in `c` there are special functions that reallocate and is not done by implicitly (but I understand someone could write a function that does it).
Thus it appears that borrow checker's behavior is guided by bad designs in other languages. When bad design is patched with more design, the latter often becomes non-intuitive and restricting. That seems to have happened with the rust's borrow checker.
In C++? No. The vector container is auto resizing. When it hits capacity limits it doubles the size of the allocation and copies the contents to the new memory. An insertion operation will give you an iterator reference to the newly inserted value, but all existing references may or may not remain valid after the call.
This meant “guided by bad design.” The borrow checker wasn’t written to handle this one use case. It was designed to make all such errors categorically impossible.
I got how c++ vectors work. Rust `Vec`s work similarly IIRC. But the problem in C++ is that it allowed you to make a `Vec` from a raw pointer.
Anywany, IMHO rust has thrown the baby out with bath water. To make such errors (ie bad design) categorically impossible, it also made a huge class of valid programs also impossible. And in-turn to patch that, it gave yet another bunch of stuff (IIRC `Rc`, `RefCell`) that people are supposed to learn (they have horrible interfaces IMHO) by which some of the programs could be implemented.
I think someone else should give it another shot. May be they can come up with a better solution than this "borrow checker"..
The fact we still can't get this in the US is atrocious. They have already paid the cost to implement this for the EU and Japan, but simply don't allow it for US users because... spite, I guess? Horrible.
It reminds me of when I asked for my account to be deleted from some online learning site (Udacity maybe?) And they're response was: "Nope, we only do that for European users." Like they went through all the effort of implementing a proper way to delete your data, but they just... don't do it if you're not in the right geographic area.
> The fact we still can't get this in the US is atrocious.
To be honest, I suspect that Apple is purposefully doing this to make alternatives a logistical and legal nightmare vs their own App store.
By having different rules for different countries, different fee structures, etc, Apple is basically making alternatives as inconvenient and painful as legally possible
The US not getting these features is on purpose, it makes the entire idea of "alternatives on iOS" extremely inconvenient vs just using the App store.
Apple didn't donate to Trump's inauguration, give him a gold and glass paperweight, and donate to his demolishing of the East Wing so that they would have to open up the app store in the USA
Could you elaborate? Other than the "Japan" requirement it seems legit?
I guess the requirements are pretty onerous, but they all seem like table stakes for a browser these days (Firefox or Chrome should have no problem with them, for instance.)
Well yes, but that’s because the iOS UI is single threaded, just like every other UI framework under the sun.
It doesn’t mean there isn’t good support for true parallelism in swift concurrency, it’s super useful to model interactions with isolated actors (e.g. the UI thread and the data it owns) as “asynchronous” from the perspective of other tasks… allowing you to spawn off CPU-heavy operations that can still “talk back” to the UI, but they simply have to “await” the calls to the UI actor in case it’s currently executing.
The model works well for both asynchronous tasks (you await the long IO operation, your executor can go back to doing other things) and concurrent processing (you await any synchronization primitives that require mutual exclusivity, etc.)
There’s a lot of gripes I have with swift concurrency but my memory is about 2 years old at this point and I know Swift 6 has changed a lot. Mainly around the complete breakage you get if you ever call ObjC code which is using GCD, and how ridiculously easy it is to shoot yourself in the foot with unsafe concurrency primitives (semaphores, etc) that you don’t even know the code you’re calling is using. But I digress…
You don’t do that by accident. Fixed-width strings are thoroughly outdated and unusual. Your mental model of them is very different from regular C strings.
Sadly, all the bug trackers are full of bugs relating to char*. So you very much do those by accident. And in C, fixed width strings are not in any way rare or unusual. Go to any c codebase you will find stuff like:
char buf[12];
sprintf(buf, "%s%s", this, that); // or
strcat(buf, ...) // or
strncpy(buf, ...) // and so on..
Thats only really a problem if this and that are coming from an external source and have not been truncated. I really don't see this as any more significant of a problem than all the many high level scripting languages where you can potentially inject code into a variable and interpret it.
There are certainly ways in which the c library could've been better (eg making strncpy handle the case where the source string is longer than n) but ultimately it will always need to operate under the assumption that the people using it are both competent and acting in good faith.
Now, prior to this, I lived in California for many years from 2011 until 2019, and I saw tons of EV charging stations there. I left with the impression of “wow, charging stations are everywhere”, and that was 7 years ago.
But now in my Midwest metro area, I can honestly say there are zero that I can think of within a 10 mile radius of my house. Not one. (They’re out there somewhere, but they gotta be tucked away because I never notice them enough to remember them.)
It’s no small wonder that all my friends from California drive electric cars, and all my friends from this area (near my childhood home, so I know lots of people) think EV owners are crazy. [0]
If EV charging stations were visibly everywhere and charged in 5 minutes I could say without a doubt that every one of them would be swayed. So I don’t think they’re being irrational at all.
- [0] It is common to go on long road trips here, since the weather sucks, and people really don’t want to rent a car to do it. Plus a ton of people tow shit. Half my friends have campers and the other half have boats.
reply