> This is still $150M of pure gravy every single year.
The issue is rate of return. They are evidently spending $4.85bn on Xbox per year. The US federal interest rate is 3.5% so if you just put that money in US bonds you would get about $175M per year of much purer simpler gravy.
Sometimes you get there by accident. You make a thing, it grows or is used in unexpected ways, now suddenly performance matters.
Sometimes Python is just the language used in the domain. Lots of sciences live on Python because it is easy to teach to grad students and the package ecosystem is strong.
Read this as: "we get discounts, rate limit increases, a direct line to responsible product managers; in exchange we participate in friendly marketing." It's extremely common in this line of business - typical of database vendors, software tool companies, etc.
No, but they go on strike when negotiating their collective contracts, and put terms in the contract that govern how failures like this are investigated and punished.
> A correction was made on May 6, 2026: An earlier version of this article misstated the country where Guy Goma grew up. He is from the Republic of Congo, not the Democratic Republic of Congo.
Right guy, wrong Congo! You can't even make this stuff up.
That's a pretty interesting idea! I guess 160+ is sort of doing some of that for us - it compiles to SQL WHERE clauses, right - but generally, we found good results giving it a SQL dialect directly.
I think some of the reason is that there's so much coverage of writing SQL in its training set.
Yes! This works really well from Sonnet 4.5 onwards, in our experience. Sonnet 4.0 was a little rocky - we had to give it tons of documentation - but by now it works without much effort.
One thing that works very well is just giving it one or two example valid programs/statements in the custom language. It usually picks up what you're getting at very quickly.
When it slips up, you get good signal you can capture for improving the language. If you're doing things in a standard agent-y loop, a good error message also helps it course-correct.
"Cheap" how? I have a friend who works on Seattle's bus planning. Removing a stop is a _lot_ of political work. When an elderly person depends on that bus stop being within a block so they can get to their doctor, and you're proposing to move it six blocks further away, that's essentially a _political_ cost.
It might better in the system throughput, and those benefits may even outweigh the misery put on that one person. But in the US, we largely sort that out by using cool-down times, hearings, and "community input."
Net result, according to my friend at least, is that bus stops feel _very_ sticky and hard to change.
I feel like I see an independent low-noise phone project like, every 3 months. Clearly there is some latent demand here. I wonder why the big players (Google, Apple, Samsung, HTC) haven't made a big-corp product for this market.
I am always reluctant to jump on with these independent ambitious projects. The first version is understandably rough, and the company seems to fold before they get to a second or third version.
But maybe advances in manufacturing in China are making high-quality, small-batch products like this more tractable?
"But accepting the full S3Client here ties UploadReport to an interface that’s too broad. A fake must implement all the methods just to satisfy it."
This isn't really true. Your mock inplementation can embed the interface, but only implement the one required method. Calling the unimplemented methods will panic, but that's not unreasonable for mocks.
I use DuckDB today to query Iceberg tables. In some particularly gnarly queries (huge DISTINCTs, big sorts, even just selects that touch extremely heavy columns) I have sometimes run out of memory in that DuckDB instance.
I run on hosts without much memory because they are cheap, and easy to launch, giving me isolated query parallism, which is hard to achieve on a single giant host.
To the extent that its possible, I dream of being able to spread those gnarly OOMing queries across multiple hosts; perhaps the DISTINCTs can be merged for example. But this seems like a pretty complicated system that needs to be deeply aware of Iceberg partitioning ("hidden" in pg_lake's language), right?
Is there some component in the postgres world that can help here? I am happy to continue over email, if you prefer, by the way.
firetiger.com, previously twitch/aws, i like woodworking
[email protected]