I work on pgrust. We shouldn't have submitted the preview when we did: it was still in active development, and its SQL coverage was far too narrow, though there was nothing in it giving it an unfair performance advantage
For the other two claims in the removal PR, we wrote scripts you can use to verify the behavior of the original 0.4-preview binary:
- Per-query kernels did not serve the benchmark queries[0]
- The preview's fast repeat LIKE queries came from a dictionary filter cache, not a cached query result[1]
Our open-sourced 0.4-beta has now been merged and is back on ClickBench[2][3]
Across all queries and instance sizes on ClickBench, 0.4-beta is ~7% faster overall than the 0.4-preview binary that was removed. If 0.4-preview's numbers had come from hardcoded kernels or faked results, the open-source general engine wouldn't be beating it
Yeah, I bought an inverter from eBay, and a battery from AliExpress. Also signed up to axle energy to reduce payback period. Most people would need an electrician to connect it though. If you just asked an electrician for a new circuit with a simple route to an isolator, it wouldn't be expensive.
> but this time the author and his wife pushed harder for it to happen
This is the essence of how to make the medical system work for you. Advocate for yourself. AI helps know what to ask, why you should ask, and how to get past the first few layers of dismissals.
You don't understand. They were only able to feed in information that they obtained with their human medical team. So the AI was heavily constrained in what it knew.
Again, this seems more like an indictment of the American medical system than kudos for AI.
For the developers here, consider: "So our CI pipeline is super flaky, and it you have to restart it in a variety of non-intuitive ways. LLMs have been a massive breakthrough because the bot can run in an endless loop reading the confusing error messages and retrying the pipeline with different environment variables until it passes!"
The difference is that lawyers typically charge by the hour. Software is not sold based on how long it took to create.
So, if a lawyer bills $1000 for "10 seconds of work", it smells fraudulent.
If $1000 was a flat rate, then it's similar to software: you're purchasing some IP and passing off legal liability to the lawyer. How long the lawyer spent on it doesn't matter.
In the lawyer's case one might argue that it's just a time quantization inaccuracy. There's no smaller unit of time than an hour for them.
One can argue that there should be, but billing in 10 second increments might also be a bit much to ask.
One would hope that they would at least aggregate multiple smaller-than-resolution time blocks into one before billing though. (Five documents over the course of a week ends up costing the same)
The fee agreement was an hourly rate for producing a legal document. The resulting document looks like it took 10 seconds to produce. The lawyer billed $1000 worth of hours.
So, either the document was much more complex than anticipated (in which case the lawyer should have said so), or the lawyer inflated the hours.
And that would be fine, if you were getting an hour of their time. If the lawyer spent 10 minutes finding the right template, 10 seconds filling it in, and then 20 minutes proofreading it, then nobody would be complaining.
In reality they'll spend 1 minute grabbing a close-enough template, 10 seconds filling it in, 3 minutes billing you, and 55 minutes double-dipping by doing work for other clients.
Go shipped with generics (aka bounded parametric polymorphism), but only for built-in types: slices, arrays, and maps. That, with subtyping via interfaces, handled most demand for generics. The most common pain point was custom containers.
Go was first released in November 2009. Russ Cox posted "The Generic Dilemma" [1] in December 2009. The comments show the generics debate raging from the earliest days.
As a fun side note, I forgot I posted a comment on that post pointing to Ada's generics. I was in college, and Ada was our intro language.
> the designers didn't want that complexity inside Go.
Yes, with some nuance. Go's goal of writing server programs didn't require the type-system complexity and run-time hit of user-defined generics. [2]
> Go was intended as a language for writing server programs [...] Polymorphic programming did not seem essential [...] so was initially left out for simplicity.
>
> Generics are convenient but they come at a cost in complexity in the type system and run-time. It took a while to develop a design that we believe gives value proportionate to the complexity.
reply