I feel like it's pretty easy to predict what OpenAI is trying to do. They want their codex agent integrated directly into the most popular, foundational tooling for one of the world's most used and most influential programming languages. And, vice versa, they probably want to be able to ensure that tooling remains well-maintained so it stays on top and continues to integrate well with their agent. They want codex to become the "default" coding agent by making it the one integrated into popular open source software.
I think this is more about `ruff` than `uv`. Linting is all about parsing the code into something machines can analyze, which to me feels like something that could potentially be useful for AI in a similar way to JetBrains writing their own language parsers to make "find and replace" work sanely and what not.
I'm sort of wondering if they're going to try to make a coding LLM that operates on an AST rather than text, and need software/expertise to manage the text->AST->text pipeline in a way that preserves the structure of your files/text.
The parser is not the hard part. The hard part is doing something useful with the parse trees. They even chose "oh is that all?" and a picture of a piece of cake as the teaser image for my Strange Loop talk on this subject!
Writing a literal parser isn’t too hard (and there’s presumably an existing one in the source code for the language).
Writing something that understands all the methods that come in a Django model goes way beyond parsing the code, and is a genuine struggle in language where you can’t execute the code without worrying about side effects like Python.
Ty should give them a base for that where the model is able to see things that aren’t literally in the code and aren’t in the training data (eg an internal version of something like SQLAlchemy).
Static analysis just requires that you don't actually execute the code. It's possible (sometimes) to infer what methods/properties would be create without actually statically analyzing the code.
E.g. mypy has a plugin to read the methods and return types of SQLAlchemy records, I believe without actually executing them.
Obviously not globally true, but in limited domains/scenarios you can see what would exist without actually executing the code.
This just seems like panic M&A. They know they aren’t on track to ever meet their obligations to investors but they can’t actually find a way to move towards profitability. Hence going back to the VC well of gambling obscene amounts of money hoping for a 10x return… somehow
The dev market? Anthropic's services are arguably more popular among a certain developer demographic.
I guess this move might end up in a situation where the uv team comes up with some new agent-first tooling, which works best or only with OAI services.
I'm actually somewhat surprised Iran is openly telling us they are using underwater drones for this. That piece of technological advance has gone mostly under the radar (!) so far.
FYI, "The Ukraine" is politically charged wording held over from Soviet times, and implies that it is part of Russia. The independent country is known simply as "Ukraine".
There are plenty of languages with gendered country names. Ukraine is die Ukraine (feminine gender) in German and the article is necessary since changing the article changes the meaning of what you're expressing. Whenever I see/hear "the Ukraine" I assume English is their second language.
Yes but as one of the other commenters pointed out, its a charged term when it comes to Ukraine so its worth mentioning to people that use it accidentally.
What defense is there against something like this? AFAIK only a few US aircraft carriers are equipped with anti torpedo torpedoes, and one of those sitting in the straight would be pretty vulnerable.
The calculation is that of course there are defences, but if you have a big stockpile of $20K drones, and your opponent has a limited number of $2mil drone interceptors, then you can keep throwing drones and keeping your opponent busy there, and you're coming out ahead even before one finally gets through.
This is very much a 'you break it, you buy it' situation. The US should be running destroyer screens for convoys a la WW2 today, yet AFAIK the US fleet is sitting hundreds of miles out of the Persian Gulf, within bombing range, outside of easy strike range.
The navigable part of the Strait of Hormuz is only 15-ish miles wide, maybe less. There is no way the US can convoy screen anything without significant loss in sailors and ships.
The WW2 convoy situation was far easier to escort (but still quite dangerous obviously) because:
1. The Atlantic is a much bigger place, even considering common routes and chokepoints.
2. U-Boats had to surface frequently, making them extremely vulnerable to Allied air cover.
3. U-Boats had to be within visual range to strike convoys, versus the drone and missile world we live in now.
- We likely don't have the assets to move the amount traffic that needs to get through
- We probably can't protect them perfectly (we don't have maritime supremacy) so ships will still take damage and that will stop the convoys pretty quickly
I suspect the escort ships would be fine though. They can defend themselves.
So if we did start them, they wouldn't continue for long until the economic pain was pretty massive and the cost of loosing ships was worth it.
I know nothing of the rise of the underwater drone but I highly suspect they are loud and slow and no match for ships designed to look for modern submarines.
It would be cheaper just to build an oil pipeline around it than to cover insurance and risk through that Strait. It would do well to just forget the Strait exists, our conflict has taken it out of commission for the indefinite future.
Cheaper but less resilient to attacks. Pipelines are fixed infra, and are imminently targetible by even the smallest drones. One successful attack and your entire pipeline is down.
Probably a 'why not both' question though. If the US could quick deploy enough pipelines to support the entire d-day offensive back during ww2 I don't see why we couldn't do so today
Let's replace a choke point by an even smaller single static point of failure transporting highly flammable content, are you an adviser for the white house? If not you should apply
> The US should be running destroyer screens for convoys a la WW2 today,
That's harder than bombing schools, goat herders or kidnapping the leader of the most corrupt country in the world, are you sure they can still pull it off, I'm starting to think even they know they cannot anymore.
After seeing the latest white house CoD style propaganda videos and Pete "Kafir" Hegseth speeches it's clear the people in charge completely lost it
> In After the Empire, written in 2001, Todd claimed that the reason for America’s “theatrical micromilitarism” was to prove that it was still an indispensable power in a post-USSR world. In his latest work, however, he revises this thesis, arguing that it would imply attributing rational intentions to Washington.13 The American liberal oligarchy is not driven by any clear project.
Idk how big your team is of course but imo try to hire a technical writer (they’re really cheap now), it pays dividends for a long time as consistent style and keywords build up SEO reputation. This article is making the rounds, some bigger papers picked it up, it is very valuable to land it well.
Imo it might be worthwhile creating a job board that solves the “company-side” issue with the current recruitment process where 200 people will spam AI generated slop CV to every post that opens up. Some kind of account coupled with a ratelimit and you should already deliver some value to people recruiting.
Really? Doesn’t v4 locally make the inserts into the B-Tree pretty messy? I was taught to use v7 because it allows writes to be a lot faster due to memory efficient paging by the kernel (something you lose with v4 because the page of a subsequent write is entirely random).
https://www.thenile.dev/blog/uuidv7#why-uuidv7 has some details:
"
UUID versions that are not time ordered, such as UUIDv4 (described in Section 5.4), have poor database-index locality. This means that new values created in succession are not close to each other in the index; thus, they require inserts to be performed at random locations. The resulting negative performance effects on the common structures used for this (B-tree and its variants) can be dramatic.
".
1. Users - your users table may not benefit by being ordered by created_at ( or uuid7 ) index because whether or not you need to query that data is tied to the users activity rather than when they first on-boarded.
2 Orders - The majority of your queries on recent orders or historical reporting type query which should benefit for a created_at ( or uuidv7 ) index.
Obviously the argument is then you're leaking data in the key, but my personal take is this is over stated. You might not want to tell people how old a User is, but you're pretty much always going to tell them how old an Order is.
There's also a hot spot problem with databases. That's the performance problem with autoincrement integers. If you are always writing to the same page on disk, then every write has to lock the same page.
Uuidv7 is a trade off between a messy b-tree (page splits) and a write page hot spot (latch contention). It's always on the right side of the b-tree, but it's spread out more to avoid hot spots.
That still doesn't mean you should always use v7. It does reversibly encode a timestamp, and it could be used to determine the rate that ids are generated (analogous to the German tank problem). If the uuidv7 is monotonic, then it's worse for this issue.
In distributed databases I've worked with, there's usually something like a B-tree per key range, but there can be thousands of key ranges distributed over all the nodes in the cluster in parallel, each handling modifications in a LSM. The goal there is to distribute the storage and processing over all nodes equally, and that's why predictable/clustered IDs fail to do so well. That's different to the Postgres/MySQL scenario where you have one large B-tree per index.
reply