Personally I can't wait until Waymo reaches the east coast. Within the past year, my neighbor was hit in a crosswalk pushing a baby stroller (minor injuries to mom and baby, but could have been much worse). And while walking my daughter our of an kids art school, an impatient car sped past the cars stopped at the crosswalk and were a foot or two from hitting my kids. These were both human drivers. And both cases would have been avoided if they were Waymos. In the first situation, the driver was only looking forward instead of the direction they were turning.
Any mode of transportation will cause injuries, especially since other humans are on the road. So just saying "Waymos have already injured people" is kind of a meaningless comment. I do think the type of accidents matter as much as the number of incidents. For example, the video that went viral recently of a self-driving Tesla randomly making a dramatic left turn into a tree on a rural road (possibly because it misinterpreted a shadow in the road) is not a mistake a human would have made.
> And both cases would have been avoided if they were Waymos.
This is speculative. Waymos hit people too.
I agree that pedestrian infrastructure in the USA is sorely lacking. The proven solution that worked in other countries is to take measures to reduce the number of cars on the road, not try to replace every driver with a computer that can only be trained by putting stupider computers on the road first to experiment on the population.
Public transit. A subway moves literally millions more people than car infrastructure can with significantly fewer injuries - basically 0 if the platforms are built with doors or gates. Busses and cable cars, driven by professional drivers, have far lower incidence per capita of injury as well.
What I was hoping to see from your post was some stats showing Waymo incidents where Waymo is at fault. I'm not actively following this stuff, but after some googling it's hard to find anything. There's tons of links with click-bait titles and then once you click into them you see things like:
- "Waymo drove through a red light (while being driven by a human)"
- "Waymo involved in a hit and run (it recorded a hit and run by a human using it's cameras)"
- "Waymo was involved in a multi-car accident (while it was stopped with other stopped cars)".
I'm not saying they don't happen. I'm sure they definitely do. As a father of two little girls, I would feel much safer with them getting into a Waymo for a short trip than an Uber. With that said, I'm strictly talking about Waymo. I would never get into a Tesla Robotaxi.
I chased up the old email. First, apologies, it was a Cruise driverless car, not Waymo.
I informed them of the incident, and here was their response, about 24 hours after my email to them:
> Copy of CUSTOMER SUCCESS (2)
> Hi Caleb,
> I'm sorry to hear you experienced this. At Cruise we take safety very seriously and this is not the experience we’d like you to have. This issue is being escalated to the appropriate team to be looked into further. Your input is greatly appreciated as we grow our ride-hail service, We appreciate your assistance.
> Best Regards,
> Jamilla
> Cruise Support
I never heard back from them again. The incident was on sep 4, 2023, at just about exactly 4pm, in San Francisco around potrero hill, perhaps Mariposa street. The vehicle was named "Bruschetta," I believe I saw that on the back or something.
I'm interpreting what you described as a derivative work to be something like:
"Create a video of a girl running through a field in the style of Studio Ghibli."
There, someone has specifically prompted the AI to create something visually similar to X.
But would you still consider it a derivative work if you replaced the words "Studio Ghibli" with a few sentences describing their style that ultimately produces the same output?
I've just started this journey. I always wanted to get into electronics and robotics, but instead went the software route. I've picked up an Arduino and microbit over the years, but they sit collecting dust.
It may sound silly, but I asked Gemini to recommend a learning plan and it came up with a detailed plan along with time estimates in months. The first step is reading and going through all the exercises in Make Electronics (third edition) which is very hands on.
Yeah that first example is rather poor. And it uses the word boilerpate to seemingly refer to the stuff unrelated to the async code (class declaration, exception handling, main method).
I don't use Java async much, but I guess if you have a utility method named "setTimeout" than the example can simply be:
public CompletableFuture<String> fetchData() {
return setTimeout(() -> "Data Fetched", 10000);
}
public void loadData() {
fetchData().thenAccept(System.out::println);
}
They updated it for the sequel, and one example doesn't nullify thousands of years of design.
But to go down that path from a logical standpoint... Papyrus isn't on my computer (OSX) for whatever reason, and it doesn't come on Linux. Papyrus isn't a free, public font... it's licensed by its owner (ITC), so the only reason you can use it on your computer is because someone is paying a license for you to see it.
My interpretation was it was replaced with the identity function (e.g. just returning the original value). But it's only replaced if the code is determined to be a hot spot. So it would work correctly until the code was in a tight loop, then it would start failing once passed a negative number.
I gave Clojure a shot some years ago and even wrote an important tool used daily by all employees at our company in Clojure. The problem for me was maintenance. If I had to make any change to that code, I had to dive into the REPL just to understand it. Whereas with something like Java, even if something is poorly written and not documented, I can get at least a minimum understanding of the code just looking at the types.
I've been working on a large modern Java application lately and have never really felt the need for a REPL workflow even after having been exposed to it in Clojure. I tend to structure my Java code so it can be easily unit-testable and then just run the suite of unit tests (several thousand) in a few seconds as needed.
I thought most were using Apache PDFBox these days. Anyone have any thoughts on how the two libraries compare in 2025? I'm particularly interested in programatic creation of PDFs.
I know historically PDFBox is a bit lower level whereas iText was a bit more user friendly, but that's not too big of a deal for me.
PDFBox is the GOAT of backend pdf libraries. We've built incredible things with it, plus pdfjs on the front-end - full compliant e-signature, templated pdf generation, in-browser pdf editing. Looked deeply at alternatives but very happy with our choice. In particular using itext vs pdfbox feels like using WordPress vs Rails - try to build anything very serious and you will be happier you picked the more capable, lower-level library.
I use PDFBox. There are some FOSS layout libraries you probably want to add one or more of, depending on your needs.
It's disgustingly fast and capable. In one project we crunched out 150k PDF documents in less than forty minutes from roughly 6 GB input data, on a mid laptop, including a fair bit of other file types related to those documents.
Fairly low level but not hard to get started with. You might have to wrap it in a module yourself if you're using those.
Thanks. I'm using it for a side project now and have my own layout library which I may consider open sourcing. I started to question if I made the wrong decision if OpenPDF had more momentum!
It's a fine decision. The degree of control you can have is a life saver sometimes, especially if you find you need to produce documents that adhere to specific PDF standards, or need to invent some customised layout element. Allows both the quick and dirty, and the very sophisticated.
You could use both if you want, I've done it in toy projects when evaluating.
reply