I was just reading an article on how BYD's flash charger can apparently charge a battery from 10-70% in 5 min and full in 9 min. That's basically refueling speeds.
It would be helpful for the current generation of smaller electic vehicles that are fine for daily use but would need to stop every 100 miles on a longer trip in winter.
I have driven a leaf since 2016 and I can tell you that no one will do this with 100 miles between stops. Because the stops aren't at exact intervals, you might be stopping every 80 to 90 miles since you don't want to risk not getting to the next.
At that rate, you're adding time really quickly as charging might take 8 minutes but getting to and from the charger easily adds another 4 to 8 minutes. At that point you're talking about adding about 10 to 16% to your total time taken
The listed range of the car that I'm thinking of [0] is 186 miles, I was using 100 miles as the useful range in winter as there are reports that it drops by a lot in the cold, this vehicle gets the largest subsidy in the UK right now. I had been considering this as my next car even before the subsidy was announced but slightly more range would be nice.
I don’t know exactly, and I’m not an EV driver, but considering how many cars I see at supercharger stations, it seems to have a use case.
I’m guessing it’s an American thing too though, we can drive many more hours and no one is driving straight 4, let alone 5 hours going 75+ mph in an EV because no one is going to run their battery down to zero. On top of that Americans really don’t like taking long breaks on road trips because that only extends the trip that in a fuel vehicle can, well, could commonly be 6-20 hours driving in the past.
All the winning we are doing over here is quickly changing the mobility of American though. But that’s a whole different and interesting topic because it has major implications for America’s survival as a single entity that people overlook. America has held together to a large extent precisely because Americans could afford being mobile during the American century, i.e., the glue that kept the country together and made it feel like it belonged to us, an actual nation. That glue is breaking down for many reasons, one being expensive, impractical mobility.
Some Tesla owners still have free supercharging so they'll be there because it's free "fuel".
For your road trip example let's say we take a 1000 mile trip. With an EV that can be done in 6 legs (sandbagging it), maybe even 5 or 4 now. So that's 5 stops, over 16 or so hours of driving. If you average charge takes 30 minutes (sandbagging it) instead of 10, that adds 1 hour and 40 minutes or about 15% of total time. And this is pretty much worst case.
I would think that's perfectly acceptable, but that's just an opinion. It'll give you time to go to the bathroom, stretch your legs, have a bite etcetera. If you're going to be peeing in a bottle and eating while driving, yes you can do it in less time.
I would strongly suggest, the next time you do one of those trips. Time how long you actually spend at a stop, it might not be far off the 15 minute mark on average
Man, people have wildly different lifestyles than what you presume, also some of us live in colder climates where official battery numbers become a joke. Those numbers would be unacceptable for me and my family for example, annoying and disrupting every single weekend. Suffice to say we own 2 ICE cars and no electric car is coming anytime soon, the overall costs and inconvenience are simply too high.
> Man, people have wildly different lifestyles than what you presume
Likewise? If you're in the cold part of the US I can totally see your comment. But just saying, there's not that many people living there. Density wise thats really sparse. Most people live in much better climates, Europe has 1.5x the number of people of all the US and no climate that is remotely the same.
If it doesn't work for you because you're in a remote area that does get really cold, I can totally see that. But I do think that makes you the exception, not the rule. For the US, California has been setting the rules for cars for years, because that's where a lot of the customers are whether you like it or not
You don’t get 4-5 hours. During winter you get 2 if you’re lucky. 1.75 hours more likely. This is on my Ford F-150 lightning going 80 mph the entire time.
If you care about driving far, you don't drive 80 in an EV, it's that simple. It might actually be the same with an ICE, slowing down a bit might save fuel so you end up with one fewer stop so in all it might be faster. Air resistance goes up exponentially with speed IIRC.
I get it. There are worst case scenarios but you buy a car for the rule, not the exception.
I owned a 2013 leaf with a range of 65 miles or so, without fast charging port because it was air cooled. So this wasn't a proper first/only car. But it worked like a charm for my daily commute...
Did I drive 80 with it? No, 65 which was the speed limit anyway.
Did I do road trips with it? No, we used the other EV for that
It's just like software guys. There's no solutions, only tradeoffs
No, the solution is never not driving fast. There are solutions. The solution is fast charging and larger batteries like this article talks about. We’re already there, just unfortunately not in the US yet.
Just got home from visiting family a couple of hours away in the highlands here. Battery is now at 40%, it'll take almost 2 days of charging at home to get it back to 100%. Hopefully I don't have another significant open highway drive to make in the next day or so.
Also our electricity rates fluctuate based on the underlying wholesale rate. It's going to be clear and sunny tomorrow at midday. Sure would be nice to be able to set my car to charge at midday when the price is single digits cents per kw, or maybe even negative. Instead I'll just have to drip it in with the higher rates at midnight-6am and know tomorrows cheap rates will average out to a much lower cost.
TLDR: definitely useful even for people who charge at home.
You talk about rates, but if you care about that, this is a no brainer. You can go to that super charger and charge in 10 minutes. You'll just pay triple your home rate though? So if you care about cost, you would never charge anywhere else.
Also, you say you need 2 days of charging to recoup 40 to 50% of battery (assuming you don't typically charge to 100 which you shouldn't). This implies you charge from a normal outlet. That's fine and I've been doing that for years, but if charge time was an issue you could have a level 2 charger at home and cut that time in 4 or something with not that big of an expense.
super charger rate is typically 6x for me. What's the cost multiple difference when my rate is negative (i.e., I'm being paid to help load shed from the grid)?
Anyway this wasn't meant to be a debate about rates. Just that "nobody that charges at home would want this" was an overly reductive claim.
The model isn't trained, it isn't differentiable (read carefully to the end: they say their model might still work if they made it differentiable, but they don't know), and it isn't clear IMO it could ever be made trainable (what is your loss function that scores a "partially correct" program / compiler, and how are you getting such training data?).
You need non-linearity in self-attention because it encodes feature / embedding similarities / correlations (e.g. self-attention is kernel smoothing) and/or multiplicative interactions, it has nothing to do with determinism/indeterminism. Also, LLMs are not really nondeterministic in any serious way, that all just comes from tweaks and optimizations that are not at all core to the architecture.
My current stance with reviewing code is: It's not ok to make another human review the code you made with AI, if you used AI then you're the reviewer, so unless you come to me with a well defined question or decision to make, just merge it and take responsibility.
Obviously that could only work in a high trust environment, that why open source suffers so much with AI submissions.
I really dislike this idea of testing in go: only ever use an interface, never the real implementation + mockgen the mocks based on this interface + use the mocks to assert that a function is called, with exactly this parameters and in this exact order.
I find this types of tests incredibly coupled with the implementation, since any chance require you to chance your interfaces + mocks + tests, also very brittle and many times it ends up not even testing the thing that actually matters.
I try to make integration test whenever possible now, even if they are costly I find that the flexibility of being able to change my implementation and not break a thousand tests for no reason much better to work with.
I'm a fan of writing tests that can be either. Write your tests first such that the real dependencies can be run against. Snapshot the results to feed into integration test mocks for those dependencies so that you can maintain the speed benefit of limited test scope. Re-run against the real dependencies at intervals you feel is right to ensure that your contracts remain satisfied, or just dedicate a test per external endpoint on top of this to validate the response shape hasn't changed.
The fundamental point of tests should be to check that your assumptions about a system's behavior hold true over time. If your tests break that is a good thing. Your tests breaking should mean that your users will have a degraded experience at best if you try to deploy your changes. If your tests break for any other reason then what the hell are they even doing?
> I really dislike this idea of testing in go: only ever use an interface, never the real implementation + mockgen the mocks based on this interface + use the mocks to assert that a function is called, with exactly this parameters and in this exact order.
Same I have zero confidence in these tests and the article even states that the tests will fail if a contract for a external service/system changes
I see this kind of testing as more for regression prevention than anything. The tests pass if the code handles all possible return values of the dependencies correctly, so if someone goes and changes your code such that the tests fail they have to either fix the errors they've introduced or go change the tests if the desired code functionality has really changed.
These tests won't detect if a dependency has changed, but that's not what they're meant for. You want infrastructure to monitor that as well.
If you're testing the interface, changing the implementation internals won't create any churn (as the mocks and tests don't change).
If you are changing the interface, though, that would mean a contract change. And if you're changing the contract, surely you wouldn't be able to even use the old tests?
This isn't really a go problem at all. Any contract change means changing tests.
> only ever use an interface, never the real implementation + mockgen the mocks based on this interface + use the mocks to assert that a function is called, with exactly this parameters and in this exact order.
is not ideal, and that's what we don't do. We test the real implementation, then that becomes the contract. We assume the contract when we write the mocks.
They mean the dependencies. If you’re testing system A whose sole purpose is to call functions in systems B and C, one approach is to replace B and C with mocks. The test simply checks that A calls the right functions.
The pain comes when system B changes. Oftentimes you can’t even make a benign change (like renaming a function) without updating a million tests.
Tests are only concerned with the user interface, not the implementation. If System B changes, that means that you only have to change your implementation around using System B to reflect it. The user interface remains the same, and thus the tests can remain the same, and therefore so can the mocks.
I think we’re in agreement. Mocks are usually all about reaching inside the implementation and checking things. I prefer highly accurate “fakes” - for example running queries against a real ephemeral Postgres instance in a Docker container instead of mocking out every SQL query and checking that query.Execute was called with the correct arguments.
> Mocks are usually all about reaching inside the implementation and checking things.
Unfortunately there is no consistency in the nomenclature used around testing. Testing is, after all, the least understood aspect of computer science. However, the dictionary suggests that a "mock" is something that is not authentic, but does not deceive (i.e. not the real thing, but behaves like the real thing). That is what I consider a "mock", but I'm gathering that is what you call a "fake".
Sticking with your example, a mock data provider to me is something that, for example, uses in-memory data structures instead of SQL. Tested with the same test suite as the SQL implementation. It is not the datastore intended to be used, but behaves the same way (as proven by the shared tests).
> checking that query.Execute was called with the correct arguments.
That sounds ridiculous and I am not sure why anyone would ever do such a thing. I'm not sure that even needs a name.
The last batch of juniors we hired just completed 4 years in the company, which I would say is a pretty successful batch, but sadly we haven't hired juniors since.
Edit: I must qualify that this is for software developers only, we did hired juniors for things like data engineers, security, IT and such.
Implement the simplest thing that works, maybe even by hand at first, instead of adding the tool that does "the whole thing" when you don't need "the whole thing".
Eventually you might start adding more things to it because of needs you haven't anticipated, do it.
If you find yourself building the tool that does "the whole thing" but worse, then now you know that you could actually use the tool that does "the whole thing".
Did you waste time not using the tool right from the start? That's almost a filosofical question, now you know what you need, you had the chance to avoid it if it turned out you didn't, and maybe 9 times out of 10 you will be right.
As far as I know there is no way to do Promise like async in go, you HAVE to create a goroutine for each concurrent async task. If this is really the case then I believe the submition is valid.
But I do think that spawning a goroutine just to do a non-blocking task and get its return is kinda wasteful.
You could in theory create your own event loop and then get the exact same behaviour as Promises in Go, but you probably shouldn't. Goroutines are the way to do this in Go, and it wouldn't be useful to benchmark code that would never be written in real life.
I guess what you can do in golang that would be very similar to the rust impl would be this (and could be helpful even in real life, if all you need is a whole lot of timers):
func test2(count int) {
timers := make([]*time.Timer,count)
for idx, _ := range timers {
timers[idx] = time.NewTimer(10 * time.Second)
}
for idx, _ := range timers {
<-timers[idx].C
}
}
This yields to 263552 Maximum resident set size (kbytes) according to /usr/bin/time -v
I'm not sure if I missed it, but I don't see the benchmark specify how the memory was measured, so I assumed the time -v.
reply