no it's like a continuation of your credit card for recurring payments.
It's called Automatic Billing Updater (ABU)
the idea is that if you ask for a new credit card after being stolen, your say utility providers or other like netflix subscriptions can seamlessly switch over to the new credit card number.
it worked fine for a while, but of course the problem is that afterwards the stolen credit card credentials started to be refreshed as well.
(used ai to fetch the list below).
Visa: Visa Account Updater (VAU)
Mastercard: Automatic Billing Updater (ABU)
American Express: Cardrefresher
General: Recurring Payment Tokenization
I’m a bit confused why so many people are commenting as if bus stop balancing doesn’t work or that transit riders won’t accept it. From 2010s and 2020s plenty of transit agencies across America have been implementing bus stop rebalancing in Los Angeles, San Francisco, dc, Seattle etc and generally it’s been successful with speeding up buses.
Of course there most of the low hanging fruit with notorious like bus stops every 200/300feet are a lot fewer and the remaining ones to rebalance are a lot harder
lack of light is generally the leading hypothesis for why there is a myopia epidemic actually. from people being indoors most of the time for school or work.
though unfortunately scientists are still researching if it is a specific frequency of light etc... people are missing
The largest problem were around behavior around nil in golang and what to convert into json and vice versa.
* The v2 will now throw an error for invalid characters outside of ut8 (before silently accepted it) which meant one had to preprocess or process again the json before sending it off to the server
* the golang nil will be converted to json empty array or map (for each type). previously it was converted to json null.
* json field names will be converted to golang names with case sensitivity. before it was case-insentitive and would be lowercased. this kinda caused lots of problems if the field collided. (say there's bankName and bankname in json)
* omitempty was problematic as it was used for say golang amount: nil would mean omit the field in json as {} instead of { amount: null}. however it also meant that the golang amount: 0 would also be omitted as { amount: 0 } which surprising. the new omitempty will only do so for nil and empty arrays/hashmaps but no longer for 0 or false. there's a new omitzero tag for that.
yeah I agree it is kinda confusing. types and interfaces used to be more separate but now they're kinda converging where its confusing when to use which.
I don't think typescript can ever be too strict, there's lots of other regular javascript files and libraries typescript will need to interact with. True it gives you plenty of escape hatches, but the point is to have less escape hatches than javascript. Your team can discuss what should or shouldn't be allowed, I'm not sure how having strict typescript is really solving the problem of mis-aligned expectations for what is allowed code.
Regarding the non-null behavior I've found that the real problem usually isn't with the variable's type definition but with it being a 'global' or not properly defined with the constructor. One can't define it as non-null because they don't know when it is constructed aka they add a property to a class that they plan on adding later when they should probably either fetch that property first or ensure it is done in the constructor.
To be slightly fair you do get similar stuff in say java where interfaces slowly gained default methods and got closer to abstract classes.
Your comment reminded me about the html over websockets article a couple days ago https://news.ycombinator.com/item?id=26265999, though the general consensus seemed to be against it.
Yeah it is quite interesting how everything goes in cycles.
If you don't have types you still might not know what to pass in. I mean if it says function( id, filePath, newStudent) is id a number or a string. Or say filePath perhaps you have a defined class for that instead of passing in a string. Sure you could write it as function( idNumber, filePathString, newStudentClass) but you're just reimplemting types as a naming scheme that isn't able to be checked compile time.
Assuming you mean rename the next version of a programming language — I think that’s a horrible idea. The entire point of continuing with the previous name is that eventually the community will move onto the new language. I’m guessing Perl 6 made too many incompatible changes from Perl 5 though I don’t know much about them.
like
Visa: Visa Account Updater (VAU) https://developer.visa.com/capabilities/vau Mastercard: Automatic Billing Updater (ABU)
it worked fine for sometime, but the problem is that now the stolen credentials are being refreshed now as well.