HN user
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.
Yeah, that'd be nice.
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.
Unless the contents of the ebook are my property, in which case you have stolen my property.
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.
The parents are the ones with money to spend, which means they're the ones advertisers want.
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.
just FYI, it's MANPADS -- the S isn't for plural, it's for "System" (as in "MAN Portable Air Defense System)
If you say so, dude.
You're confusing the concepts of "immoral" and "illegal".
There's a difference between "the executives are bad people doing a bad thing that is _maybe_ tortious" and "the executives are committing a crime".
OP was claiming the latter is rare. You're saying the former is common. They're not the same thing though.
Paying someone a lot doesn't magically make them a good engineer. You have to actually hire the best people, and there's only so many of them to go around.
Georgetown has the School of Foreign Service, which has tougher admissions standards than the other 3 Georgetown undergraduate schools, and is the #2 ranked undergraduate program in blah blah blah but seriously the number of people who turned down Harvard for Georgetown SFS was very small, whereas the number of people in the SFS with a big chip on their shoulder because they didn't get into Harvard was very large. (I, personally, did not get turned down by Harvard because I had zero chance of getting in and so did not waste any money on filing an application and was happy to even get admitted to Georgetown.)
CMU has 7000 undergrads, of whom 600 are in the School of Computer Science. So, if you take a random CMU student who decided to start a company and looked for VC funding, you've got a <10% chance of an SCS alum and a 90% chance of a non-SCS student (assuming likelihood of starting companies is uniform, which who knows if it is but I have no reason to assume otherwise). Whereas at Stanford 100% of students had to get into Stanford.
I'm a Georgetown alum. Georgetown alumni do the same thing with international relations that CMU alumni do with CS where we like to pretend that because there's a really good IR graduate program that we undergrads were somehow special because of that.
Also, as with CMU, there are definitely more people who are interested in the topic, and a subset of them really are quite talented, but the talent density just isn't as high as at HYPS/MIT/Caltech, and as you noted, the talented people aren't as well-rounded (because if they were, they would've gotten into HYPS/MIT/Caltech).
Berkeley is not that hard to get into for in-state students (much easier than CMU or Georgetown). But, yes to Stanford/MIT/Caltech.
The standard top 4 is HYPS (plus MIT and Caltech)
In other news, Stanford is one of the four best undergraduate programs and Carnegie Mellon is... not.
Don't get me wrong, CMU has a great computer science faculty, but looking at random CMU alumni doesn't tell you much because a random CMU grad isn't that different from a random Georgetown grad.
"this looks about right and has no obvious bugs" is my standard when reviewing human code, and it's my standard for machine-generated code too. no reason to formally verify GPT-4 outputs if I'm not formally verifying my coworker's either.
Some discussion of trying to get it to run, if you're curious what folks have been trying: https://www.reddit.com/r/LocalLLaMA/comments/13wutj4/getting...
Falcon 40B is allegedly the closest thing out there. It sure beats the hell out of all the other open source models I've tried, but good luck finding hardware that can run it.
in public administration, in military, as well as in private sector, in areas like compliance, due diligence etc.
agree 100%. The commonality there is that these are things where the profit motive can't discipline wasteful management.
I'd also throw in the non-profit sector in general, in addition to what you listed. Without ongoing hard work by donors to prevent waste, non-profits become very good at incinerating all their money on excessive overhead.