The reason it works with `String` is because trait methods get priority over applying autoderef (which is needed to go from `&String` to `&str` and select `str::strip_suffix`). If you however already have a `&str` then autoderef won't be needed and the inherent method will win over the trait method. At no point does the prelude come into play
It generally depends on the contract the merchant has with payment provider:
- some have relatively high merchant fees to cover for interchange fees
- others (generally called IC+) have the merchant pay the IC fee plus some other (generally much smaller) fee to the payment provider
In both cases it's the merchant that ends up paying them. It's not a concidence that in Europe (where there are caps to IC fees) the fees that merchants pay are generally lower.
> we must assume that the best AI models (especially ones focusing solely in the medical field) would largely beat large majority of humans (aka doctors), if we already have this assumption for software engineers
You first have to assume this for software engineers. Not everyone agree with that (note: that doesn't mean the same people don't agree that AI is not _useful_).
AIs still have a ton of issues that would be devastating in a doctor. Remember all the AIs mistakingly deleting production DBs? Now imagine they prescribed a medicine cocktail that killed the patient instead. No thanks. There's a totally different bar to the consequences of mistakes.
In some subfields, like detection of security weaknesses in obscure C code, AI is already better than software engineers.
It is capable of sifting through enormous reams of data without ever zoning out etc. Once patients routinely use various wearables etc., they, too, will produce heaps of data to be analyzed, and AI will be the thing to go to when it comes to anomaly detection.
I don't think this is a fight doctors can win. We programmers make mistakes all the time.
At one place, we had a QA lead who was burned so many times she would insist that she will find the time to do at least a full smoke test even if we promised it was a small contained change in the frontend. I have no idea how she found the time because she wore multiple hats.
Doctors make errors all the time though, so the real argument is about the error percentage. If AIs is lower then it's safer (but it's hard to have that convo, I recognise).
Besides; this article was about diagnosis not prescribing. It's pretty obvious, I think, that diagnosis is one area where AI will perform extremely well in the long run.
I think there are two metrics; the first is outright misdiagnosis, which studies put between 5 and 8% in US/Europe. That's a meaningful number to tackle.
Secondly; overdiagnosis. Where a Dr says on balance it could be X on a difficult to diagnose but dangerous problem (usually cancer). The impact of overdiagnosis is significant in terms of resources, mental health, cost etc.
I agree with you, but seperate point in many respects - the conversation was about replacing existing robust medical infrastructure.
I fully agree that AI could extend access; but to build on what others have said too, lack of physical diagnostics is an issue as is the lack of physical tech infrastructure.
Do you believe the issue is because they don't have enough technicians to diagnose or because they don't have enough x-ray machines?
Or in a ER environment, how an AI would speed up things in a real way that improves patients' lives?
We just minted the term "cognitive debt" for software engineers that cannot keep up with what the AI spits out. How would that apply to ER doctors, or any other kind of doctor?
I'm not talking in particular about the X rays. It's about general lack of hospitals, equipment and doctors.
In Europe, there are some rich cities which have on average one doctor per hundred people. And there are large areas in Eastern Europe that have ten times less than that.
If you have some unusual symptoms or a little pain somewhere and no access to doctors you will most likely ignore it.
If you can get any diagnosis it can help you e.g. decide to travel to get treatment.
And the locally available alternative for ai diagnosis is a doctor you can get to in few months, who works 80 hours a week and has 10 minutes per patient.
For ai to be valuable you really don't need to be better than average physician in top American clinic.
> That's am upper bound, as using a nightly compiler doesn't mean that a nightly compiler was needed.
To be fair it's not even a lower bound, as using a stable compiler doesn't imply the absence of nightly only feature (as in Cargo features, the ones you can enable on crates you depend on).
For the purposes of this discussion the question is not whether or not a crate exposes optional features that require a nightly compiler, but whether or not a crate makes use of the nightly compiler mandatory, which has become extremely rare in my experience. Perhaps it's more common in some embedded use cases, but if people want to make that assertion, I would ask that they either mention which libraries they're specifically talking about or which nightly features they're specifically referring to.
I think the divide is apps vs libraries: a library that requires their dependants to set an environment variable opting out of stability guarantees is unlikely to gain adoption, but applications that do so are more common, like Firefox.
> For the purposes of this discussion the question is not whether or not a crate exposes optional features that require a nightly compiler, but whether or not a crate makes use of the nightly compiler mandatory
In my opinion what matters is the functionality. If it's provided by a nightly-only crate or as a nightly-only feature of an otherwise non-nightly-only crate it doesn't really matter.
But I agree that this is become more and more rare.
reply