UV also has the distinct advantage in dependency resolution that it didn't have to implement the backwards compatible stuff Pip does, I think Astral blogged on it. If I can find it, I'll edit the link in.
That said, your point is very much correct, if you watch or read the Jane Street tech talk Astral gave, you can see how they really leveraged Rust for performance like turning Python version identifiers into u64s.
I was lucky enough as a young child to see one of these working a high country farm - it was operating off a sloped runway and I was convinced it was going to crash as it landed uphill, then convinced it was going to crash after it took off after reloading due to how slowly it climbed - I can't find a definitive number, but I vaguely recall it had a take off speed that lurked around 50kt...
On the subject of top-dressers... ...I was privileged to see a turboprop equipped Fletcher FU-24 in action a couple of weeks ago, those pilots are very darn good at flying very low in hill country. Very loud and notable engine sound.
50 knots rotation is perfectly fine for a plane that size. A Cessna Skyhawk is certified to rotate at 55 knots fully loaded (and since the stall speed is around 40knots, for specialty take-offs like soft fields it's much lower, 50knots is more than enough).
See also the Caproni Transaero, which isn't totally ugly but is messy in a "maybe more wings is better? some pushing engines at the back?" kind of way.
The fairy gannet looks like two smaller airplanes clipping into each other. It looks like an AI from ten years ago generated an image of an airplane. It looks like they hired engineers who got their degrees in Kerbal Space Program and then paid them by the hour. "Even if it's broke, it doesn't have enough features yet."
It was designed to carry to operate from very rough "airstrips" which is a very optimistic term for "a paddock that the farmer hopefully mowed recently and if you're lucky, they also removed most of the bigger stones".
I also imagine in the postwar WW2 antipodes, steel was a lot easier and cheaper to access, as well as work.
I did find the Waymos in SF disconcerting as they approached pedestrian crossings while I was waiting - with a human driver there's many different cues that they've seen you and noticed you - whether it be looking directly at you, or slowing down in preparation for you to cross.
I'm sure if I had just started walking across the crossing it would have reacted perfectly, but I wasn't willing - based on the lack of observable "I have noticed you" cues - to test that theory.
That combined with the parent's post is, perhaps counterintuitively, somewhat concerning.
The proper technique for yielding to pedestrians wishing to cross is to start slowing down early, as if you were planning to stop before the crossing. That sends a clear signal to the pedestrian they're good to start crossing. Then you're free to speed back up. This is very comfortable for the pedestrian and the vehicle never needs to stop, so the slowdown is minimal.
That Waymos apparently don't act this way and seem to need to send an explicit signal to pedestrians sounds concerning to me, even if its ultimately safe.
Waymo does slow down as it approaches stop signs (usually where crosswalks are) and it will slow down if there is a pedestrian entering the roadway (crosswalk or not) since it doesn't want to crash into them.
The explicit signal of a driver noticing you (eye contact) is replaced by the signal above the vehicle. Are you not equally concerned that pedestrians have to get an explicit signal from drivers who are legally required to yield or stop??
Ah, so this particular pedestrian crossing wasn't at a stop sign (we were at the big historic army place out by the Golden Gate bridge) so that might explain it.
If Canada is like New Zealand, which also has a similarly high rate of gun ownership - it's largely different types of guns - that is, guns for hunting, not for killing people - very hard to conceal a rifle or shotgun compared to a pistol.
Seeing as we're having a $LANG war, after 15 years in JVM land, I moved to a Python / Go shop, and fuck I miss Java.
Not so much the language (although modern Java is pretty slick), but the stuff surrounding it.
* No typosquatting issues because every package has a group id verified by real humans and DNS TXT records.
* JMX as a standardized mechanism of exposing ways to interact with running code / expose metrics. (Even if you have to deal with the stupid ass protocol where you have to connect using a DNS identity the JMX server recognizes)
* Logging libraries that give people running the code control over what gets logged and how, not the developers (looking at you Golang, wtf is with your logging approach where devs have to explicitly consider the fact that you might want to run logging at DEBUG and code it into your start up args?)
* The ability (via JMX) to set, at runtime, one particular logger in one class or file to a desired logging level without restarting the application.
* The performance of the JVM.
* The vast FOSS ecosystem.
* Not having to fight C build chains for that one dependency that's using CGo or a Python wrapper around a C lib that no wheel supports for your given tuple of Python version, OS, and architecture.
Honestly, as someone who is a self-taught developer who taught himself in Python, I thought I was coming home to my first love.
Turns out, I really hate the horrible things you can do in Python - looking at you Django, don't be so dynamic your brains fall out - and really dislike the experience of trying to run a Go service compared to a JVM service.
Java and its ecosystem is just good at getting shit done in a predictable manner at both the dev level and ops level.
> * No typosquatting issues because every package has a group id verified by real humans and DNS TXT records.
While I think this is a huge boon, have you ever published a package on the Maven Central repository? I must confess I haven't in a few years now, but when I did until ~3 years ago it was a major pain in the ass. And every release again.
I think there's something to say about Go's model where the package is just in some Git hosting and a release is just creating a tag. As a package maintainer, this is just pure bliss compared to the Maven thing.
> and really dislike the experience of trying to run a Go service compared to a JVM service.
What are you running into specifically? I have the complete opposite experience. With Go, 1 small binary comes out that I can run anywhere (and put into a distroless container), whereas with Java I have to find a way to somehow run a full JVM (most often with (large parts of) an OS too).
Perhaps you're alluding to the things you can do with JMX, but I have never really seen much benefit in that. I found it trivial to add similar functionalities with internal HTTP endpoints easily. But since I don't have much experience in this particular area, probably I'm missing something.
> While I think this is a huge boon, have you ever published a package on the Maven Central repository? I must confess I haven't in a few years now, but when I did until ~3 years ago it was a major pain in the ass. And every release again.
I’m really surprised to read this. It is well-documented process. I regularly publish something there, never had problems. Why was it different for you?
Yeah, publishing a package is a PITA for the precise reasons of maintaining trust in, and the quality of the packages.
That's why you need documentation to publish to Maven central, that's why your package needs to specify its license, GPG checksum etc.
Yep, it's a lot harder than publishing to Pypi or Cargo, but I'm now firmly of the opinion that it's good that it is. The gates between you and publishing a package are there for deliberate reasons.
> Perhaps you're alluding to the things you can do with JMX
Yep, specifically things like "set the logger org.foo.package.Bla to DEBUG while the app is running", without restarting and without having to add an internal HTTP endpoint to be able to accomplish that. It's just there for free, every JVM logging library and metrics library exposes itself via JMX for that same reason - ease of observability, without restarts, without custom code.
E.g., I can access Kafka client metrics via JMX anytime I like. JConsole will even give me pretty graphs.
If I want them in Prometheus, I run the app with a Java agent that takes those MBean metrics and exports them in Prometheus format on an HTTPS endpoint.
I understand you can accomplish much the same with some internal HTTP endpoints, but that presumes they exist.
If you need them, but that microservice hasn't deliberately exposed them, you need to change the code, and then make a new release, which slows down your ability to diagnose what's going on right now.
In Java, every observability library exposes itself via JMX, all you had to do as a sysop was ensure that the JMX port was open.
Also, the ability to easily observe the metrics of the VM itself via JMX so I can see what's going on with GC in a running app without having to explicitly expose that.
If you suspect a memory leak, or something that should be GC-able isn't, or that there's far too many object allocations occurring that's smashing the first gen portion of the heap and causing excessive GC pauses, the instrumentation to investigate it as your app runs is right there, it's baked into the JVM.
That's why I miss it - the JVM was built to be instrumented and observed by the people running it.
I really wish Golang and everyone else would emulate the Java approach to observable metrics as well as the Java approach to logging and packaging.
There's no shame in stealing the good ideas Java had, but no-one seems to, to my frustration.
edit wasn't Astral, but here's the blog post I was thinking of. https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html
That said, your point is very much correct, if you watch or read the Jane Street tech talk Astral gave, you can see how they really leveraged Rust for performance like turning Python version identifiers into u64s.
reply