Error logs and monitors find out because the RPC fails, which causes an error to be logged and a failed request metric to be incremented. (The UncaughtExceptionHandler will do the same for stuff failing in background threads.)
If eventual consistency is important, enqueuing for retry has to be done BEFORE you try to write, not on write failure. If/when the write succeeds, you remove the item from the retry queue.
If I need to write some bytes to an S3 bucket but the network is hosed, there's literally nothing useful I or any library can do until the network is back up.
RPC calls will fail, error logs should get written, and a monitor should get triggered, and someone should get paged so they can wake up and figure out why the network is hosed.
Nowhere in there is it useful for me to wrap all my S3 writes in try/catch blocks.
In a desktop application that is not allowed to totally crash, or at least has to crash kind of gracefully, checked exceptions are useful.
But in the world that most Java devs live in, which is various flavors of RPC server, failing requests is fine. If lots of requests fail, your monitoring infra should page someone, and that someone will go log spelunking and figure out what's broken.
Very occasionally it turns out that the thing causing the RPC failures is a recoverable exception, and then you should wrap the problematic stuff in a try/catch block. (Often you'll wind up having to detect the recoverable error case by conditioning on substrings in the exception message, which the library owners will arbitrarily change in future releases. So make sure to write regression tests so you'll catch this when you upgrade the library. Java is fun!) But 99% of the time the failure is "network is busted" or "config was invalid" or "hard disk failed" and you should not be defensively programming against all those possibilities.
You can return union types in Java if you want that, although it'd be nice to have better first class support for them.
The issue though is that forcing people to handle irrecoverable exceptions is just kind of dumb. If I do file IO, I know it'll barf sometimes. Sometimes I care, but the vast majority of the time I don't.
A lot of Java servers have RPC endpoints that basically say "write X to file Y" or "read X from file Y" and if the S3 connection is busted, there's nothing the server can do about that. Someone has to go log spelunking, figure out what's wrong (network is misconfigured, AWS is having an outage, whatever) and fix it. So it is bad API design on Java's part to make every single one of those RPC endpoints wrap every single thing that does file IO in a try/catch.
It's not a matter of laziness. Most of the time there's just nothing you can do.
Like if you try to construct a URI based on a configured URI string, and get URISyntaxException... wtf should you even do? You can't recover, because your code shouldn't be mutating config. Similarly with basically any JSON parsing exception. And most disk read/write exceptions.
And in modern applications the caller is probably on the other side of an RPC call, and checked exceptions won't propagate sanely across the RPC anyway.
Checked exceptions failed because 99 times out of 100 the exception is not recoverable, so the try/catch block is just wasting everyone's time. (In 7 years as a Java dev I can think of one time I wrote code that tried to recover from IOException instead of just making the caller retry.)
Even when the exceptions is theoretically recoverable, it has to get propagated up properly to the caller who should be handling recovery from it. But checked exceptions don't propagate sanely through executors and across RPC calls, so good luck with that.
If I use your copied credit card to buy software, all that happens is (a) some bits get written to my computer's hard disk and (b) some bits get written to a Visa or Mastercard server's hard disk. Why would you get upset about that?
EDIT: ok, it's fun playing obtuse, but more seriously it is also very obtuse to pretend that intellectual property is not property. I think you have to be pretty stupid to not understand why an author who spends a decade painstakingly creating a work of literature is entitled to ownership of reproductions of that work.
It's really about whether you can incrementally assess P&L.
Facebook has epic amounts of user-generated imagery and text, and incremental improvements in NLP and computer vision generate incremental revenue (and profit) because you can put up better ads and introduce new features like translation. As an investor, that is very appealing.
There's no incremental revenue from Metaverse. It's a huge money pit, with no obvious end date for when enough billions have been wasted to call it quits. It could well work out, but if I'm an investor why would I want to invest in this through Facebook rather than through a bunch of startups pursuing a diverse set of strategies.
Metaverse is exactly my point -- they've incinerated vast amounts of investor money with nothing to show for it. They could've and should've just plowed that money into hundreds of startups.
LLAMA is also exactly my point -- LLMs are pretty well-proven at this point. If you spend $X on machine learning researchers, you can get an LLM with Y parameters that is useful for various tasks like sentiment analysis, machine translation, etc. Facebook should be spending money on that because they have lots of cash, data centers, and ML researchers so they can do this at scale that only a few others can (Google, Microsoft/OpenAI and maybe Amazon).
If you have a billion dollars and want to do something creative, invest it in 100 startups. But if you want to spend a billion dollars through a big corporation, you should use that corporation's comparative advantage -- which is generally scale, not creativity.
Creativity is for startups. If you run the 8th or so most valuable company on the planet, your competitive advantage is mostly your scale. You should mostly be using that to maximize return on proven stuff (either by buying or copying proven things), not pissing away billions of dollars on stuff that a startup can iterate on for a tiny fraction of that price.
Claims like this are so dumb. Call center work has a very low ceiling on skill, so obviously people who are maxed out can't benefit.
But in any knowledge economy type job, there is no ceiling on skill. Creative, curious, intelligent people who are already high skill are also going to be the most effective at using a new and weird and tricky tool in interesting ways to develop their skills.
Generative AI will make some old skill obsolete, but people who are generically good at picking up new skills will be much more effective at wielding it. Those are the same people who were good at picking up the old skills, too.