But in defense of Java, modern Java is actually pretty pleasant.
Virtual threads, records and sealed classes, pattern matching, state-of-the-art garbage collectors, a great standard library etc. (and obviously well-behaved enums).
Not to mention the other languages you get for free with the JVM ecosystem.
It might not be as expressive as Rust, but certainly Java/JVM > Go.
No, I don't think HTTP or JSON are cherry-picked. Depending on what kind of code you write, maybe you haven't needed them as often as I have.
Of course, plenty of high-quality third-party libraries exist in the other languages. I've used commons-httpclient and jackson in Java, and everybody and their brother knows about requests in Python (though I prefer aiohttp nowadays). But they are odd omissions from the standard libraries of those languages. At least .NET caught up.
I use Android's Bedtime mode a lot, and it has a helpful feature that let's you quickly "Pause for 30 minutes" or "Turn off for now" from a notification [1].
I don't think the app needs notifications as such, but it could have quick access to a pause button.
Ah perhaps the app is using bedtime mode for its functionality? Didn't get a chance to try it myself yet, but great that pausing is already implemented.
The word recall sort of implies that the vehicle is recalled to the manufacturer. Calling a software update that happens in your garage at night and takes 20 minutes a “recall” definitely is worthy of quotes.
The word bug sort of implies that the device was struck by a terrestrial arthropod animal. Calling a software defect that happens due to a programming error a "bug" definitely is worthy of quotes.
(The etymology of a word can be quite different from its current meaning today.)
Focusing on the dictionary definition of the word "recall" seems pedantic.
Not all recalls are for big mechanical problems. I've received several recall notices for issues that just required the dealership to flash the ECU or some other controller with new firmware. Whether that update is flashed OTA or with a special dongle at the dealership doesn't really make a difference if you're looking at it from the perspective of vehicle safety/reliability/stability. The point is that a recall is a significant enough issue that the manufacturer _must_ notify their customers about it.
I agree that if you count _every_ OTA update as a recall, you can't really do an apples-to-apples comparison. The cost of pushing an OTA update is much lower than the cost of a recall, so Tesla probably pushes a bunch of minor OTA updates that other manufacturers wouldn't bother with. But it's a fair comparison if only some subset of OTA updates are counted as recalls (i.e. updates addressing a safety issue).
> The word recall sort of implies that the vehicle is recalled to the manufacturer.
It does not, no more than gaslighting implies lighting a gas lamp or the phrase crossing the Rubicon implies actually crossing a river in Italy, in any case. It hasn't meant anything of that sort since the mid-sixties.
Recall is what legislation requires you to call it if something is unsafe for public use and it has to be withdrawn for the market until it's remedied. It doesn't matter how that's done. The NHTSA guidelines don't include physically getting the product to a manufacturer or a distributor as a requirement to issue, or as a criteria for fulfillment, of a recall. (I don't think recall guidelines in any industry do, it's just the NHTSA's that apply in this case).
Yes, this also applies for firmware upgrades. No, it doesn't matter where they're performed. The FDA has issued firmware-related recalls for devices with programmable logic since programmable logic in medical devices was a thing so like... fourty years. If anyone in some company's safety staff just learned about that's let's all please give them a warm welcome to the 20th century.
The main reason why recalls typically involve returning the product to the manufacturer (or, more often, as the vast majority of recalls are for food, medicine or cosmetics, to the distributor) is traceability. Manufacturers need to maintain documentation that shows they took reasonable action to notify all customers, that depending on how they chose to handle it they made repairs for free, replaced them for free, or that the refund they issued made reasonable allowances for depreciation, and so on. Some foodstuffs or medicine also have disposal safety rules that require you to maintain adequate documentation as well. It's just the easiest way to deal with it, both in terms of remedying the actual issue, and in terms of legal risk.
But it's got nothing to do with returning something to the factory, it hasn't meant anything of that sort in like half a century.
Once again, an intelligent post such as yours has been lazily downvoted simply because somebody doesn't agree with it, and they can't be arsed composing a coherent rebuttable. This leads to unpopular ideas being buried, groupthink and a lack of intelligent discourse.....
....And yes, this IS leading to this place becoming more and more Reddit like (no, that isn't a tired cliché, no matter what the FAQs claim).
Downvoting needs to be reserved for comments that detract from the conversation. At this rate, we will need some form of meta moderation to ensure this happens.
> Downvoting needs to be reserved for comments that detract from the conversation.
I understand where you're coming from but truth is a post like that one does detract from the usual excusemaking conversation that some companies enjoy here, so I'm not surprised it was downvoted :-). It's one of the many ways in which karma points killed online discourse. I just happen to be old enough to have racked up a lot of pre-karma posting (including, of course, flamewars, what would life be without spice?) so downvotes don't really register on my radar.
If you think about the financial implications then probably yes. Software issues, safety related or not, can probably easily be fixed OTA and thus don’t even cause a fraction of the costs a (let’s call it "real") recall costs.
Also, in the head of most people, I think, a recall is something where the car needs to be returned physically. But still, obviously, the issues can be as serious as physical issues. It’s just that we’re used to physical recalls.
Getting an OTA software update to your vehicle is far less disruptive to your life than having to take it in to the dealer. Obviously safety issues shouldn't happen, but how easy they are to fix also matters.
"Recall" is wording that means (to me) the vehicle needs to be physically returned to a dealer workshop for something to be done.
That it's used for OTA updates just (to me) means they should use some more suitable wording for it. And yeah, as other people have pointed out it's the word used for the legislation. I still think they should use some kind of different wording though.
> pharmaceutical and biotechnology sales revenue increased from $534 billion to $775 billion between 2006 and 2015
> worldwide company-reported R&D spending, most of which went to drug development (rather than research) ... $89 billion in 2015 dollars
> During the same period, federal spending, which funded a greater amount of basic research relative to industry, remained stable at around $28 billion
So only ~11% of total revenue was being reinvested, mostly into drug development.
And basic research was funded largely by federal spending.
Drug development is a pretty critical component of getting a drug to the consumer, unless you don't consider completing human clinical trials and receiving FDA approval to be valuable
Oops! Thanks, just distraction... It's that first I wanted to see the general solution to those kind of problems (and I gave the solution for a wrong one in the class), then I wanted to verify the C implementation of the solution with POPCNT like the OP seems to have done (I am writing the code)...
Edit: ...and yes, it seems that brute-forcing (counting to one trillion) takes more time than I expected.
Now I see it. Twenty items (R operations) in 40 slots: 40!/(20!) and the order of the items does not matter, so again divide by 20!. The remaining slots are D operations.
The answer actually came to me in the shower this morning.
Looking at the code, it's not clear to me how much has broken because of the fork, and how much has broken because of the "secure context" security patch that ACF have apparently also applied in their own version.
That is, I think some of these things might have broken even with the real ACF.
The main change appears to be that if a developer has used a built-in wordpress function as a filter hook (rather than a user-defined one), that has been blocked. (This has never been a good idea, anyway; developers should not do it.) Also a filtered version of the POST variables has been passed to the callback. These are both seemingly to stop CSRF attacks.
This patch was necessary; it prevents CSRF and potentially other nasties.
I don't mean to excuse any of the other bullshit; I'm just saying that if there are "breakages" here, they are likely to do with the necessary patch that is hidden inside the gaslighting.
> this is not a hard problem to solve in idiomatic Go.
Genuinely asking, what would the solution look like in idiomatic Go?
Let's assume for a second that the premise of the article is valid and exactly the behavior we want - "asynchronous execution but to report the results in order, as each becomes available".
Send the results into a channel, with a separate goroutine that polls the channel, stores a buffer of results, and sorts and prints the latest results at a regular interval.
> sorts and prints the latest results at a regular interval
Slightly more complicated than that, because you can only sort and print elements once you have _all_ the elements that came before them. Once you add that layer you've got quite a lot more code (and potential for mistakes) than the promises version.
You could also have N channels, one for each argument, and use reflect.Select to receive the results as soon as available, waiting to print any result until all of its predecessors have come in.
You could also have a mutex-guarded block at the end of every worker goroutine to do the printing and a sync.WaitGroup to follow the workers in main.
No need for reflect.Select, just loop through the channels and wait on each. That'll do your "predecessors" part just by the sake that it's an in-order for loop.
I agree. Though to be fair Nintendo's NES is a gaming console (not that they are right, just contrasting the use-cases).
Consider Apple's very own Mac - another general-purpose computing device like the iPhone, only in a different form-factor.
Surely Mac developers must be tripping over themselves to throw 30% of their total revenue at Apple, as reward for their laser focus on privacy and security and for developing a nanny-platform that makes their users feel warm and fuzzy inside?
Surely Mac users must not be allowed to do business with literally any entity in the world without involving Apple as the gatekeeper?
I agree with your point about Go enums.
But in defense of Java, modern Java is actually pretty pleasant.
Virtual threads, records and sealed classes, pattern matching, state-of-the-art garbage collectors, a great standard library etc. (and obviously well-behaved enums).
Not to mention the other languages you get for free with the JVM ecosystem.
It might not be as expressive as Rust, but certainly Java/JVM > Go.