akshayshah

Huh - are you sure? I was pretty sure that the original implementation came from the Android & iOS repos.

I'm surprised (without any particular positive/negative valence) that the article doesn't mention using AI to write the port - especially since both CEL and protovalidate have fairly extensive conformance testing harnesses. The project should be right in the sweet spot for today's tools.

The omission is especially striking since most of the article sounds AI-authored to me. (Pangram agrees, for what that's worth.)

Very fair point that protovalidate comes from Buf, not Google.

But it's worth noting that protovalidate can also work with plain gRPC - it's an independent library, and anyone can write a gRPC interceptor that uses it. Here's a community-supported example in Go: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middlew...

I'm not sure how to think about what you mean by "almost never." If most commercial software is web frontend + monolithic app code + relational DB, then you may very well be right.

That doesn't quite match my professional experience, though - there are so many companies building databases, message queues, filesystems, and similar infrastructure. Sometimes they're internal projects, and sometimes they're commercial products. I've always felt that those systems would benefit from formal methods, since they're usually trying to provide strong guarantees to the application code on top.

It's strange to see this project on Github: the repository is basically just a README and Github sponsors config, without any source code I can see. Does the Polyform Shield license checked into the repository apply to the released artifacts? Are the the released artifacts trustworthy enough to have access to my microphone?

These days, he’s also working on Hegel - bringing test case reduction and PBT to more languages.

https://hegel.dev

This is very cool! I’m most interested in the protobuf runtime - Rust has historically used Prost, which doesn’t pass the protobuf compliance test suite and isn’t Google-maintained. Google’s priority internally is cpp interop, so they use unsafe for protobuf - which the community is understandably not excited about.

(For full disclosure, I started the ConnectRPC project - so of course I’m excited about that part of the announcement too.)

And https://arxiv.org/pdf/2310.10688 if you want the full paper.

Whoops, bad link formatting: https://x.com/patrickc/status/2015562569105465347

To be fair, the name was a joking response to https://x.com/patrickc/status/2015562569105465347…and then the temporary skunkworks name stuck, as it always does.

There’s a whole section on this on TFA: https://celbyexample.com/execution-cost/

I’d be surprised by this: GitHub pretty famously used Vitess, and I’d be surprised if each shard were too big for modern hardware. Based on previous reporting [0], they’re running out of space in the main data center and new management is determined to move to Azure in a hurry. I’d bet that these outages are a combination of a worsening capacity crunch in the old data center and…well, Azure.

[0]: https://thenewstack.io/github-will-prioritize-migrating-to-a...

In broad strokes, I think this is similar to Bitdrift (https://bitdrift.io) - though they’re focused on mobile observability.

Alas! Once again, I’ve learned what happens when I assume.

Totally fair. At least in part, I blame the choice of <em> and <strong>: it's really not clear what the hierarchy between them is, so I just think of them as the online versions of italic and bold.

<mild> and <strong>, or <em> and <emem> (or <double-em>, or <very-em>) might have been clearer, but at this point we'll never know.

Edit: apparently <i> has been redefined to be "the idiomatic text element" rather than just italic - so perhaps it's a semantically appropriate choice here after all! https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

I like Markdown, and generally agree that it strikes a nice balance between correctness and usability...

...but it's delicious that this blog post also demonstrates an ambiguity in Markdown: how to handle intra-word emphasis. In the rendered output, "mark_up_" and "mark_down_" were probably intended to be "mark<em>up</em>" and "mark<em>down</em>", but the underscores were instead rendered literally.

I do appreciate that Markdown's solution to ambiguities like this is dead simple - just inline some HTML.

At least per the Redis docs, clusters acknowledge writes before they're replicated: https://redis.io/docs/latest/operate/oss_and_stack/managemen...

The docs explicitly state that clusters do not provide strong consistency and can lose acknowledged data.

No. Redpanda has made a lot of noise about this over the years [0], and Confluent's Jack Vanlightly has responded in a fair bit of detail [1].

[0]: https://www.redpanda.com/blog/why-fsync-is-needed-for-data-s...

[1]: https://jack-vanlightly.com/blog/2023/4/24/why-apache-kafka-...

Rapid is excellent. It also integrates with the standard library's fuzz testing, which is handy to persist a high-priority corpus of inputs that have caused bugs in the past.

Testing/quick is adequate for small things and doesn't introduce new dependencies, but it's also frozen. Many years ago, the Go team decided that PBT is complex enough that it shouldn't be in stdlib.

Here's a small example of a classic PBT technique used in a very practical Go project: https://github.com/connectrpc/connect-go/blob/cb2e11fb88c9a6...

Sibling comments have already mentioned some common strategies - but if you have half an hour to spare, the property-based testing series on the F# for Fun and Profit blog is well worth your time. The material isn’t really specific to F#.

https://fsharpforfunandprofit.com/series/property-based-test...

Sometimes, sure - but sometimes, passing around a fat wrapper around a DB cursor is worse, and the code would be better off paginating and materializing each page of data in memory. As usual, it depends.

Very cool! Using “object storage for primary durability” seems difficult for any OLTP workload that’s latency-sensitive - there’s a fundamental tradeoff between larger batch sizes to control write costs and smaller batches to reduce latency. This hurts OLTP workloads especially badly because applications often make multiple small writes to serve a single user-facing request. How does EloqKV navigate this tradeoff?

Also, I’d love to see:

- A benchmark that digs into latency, throughput, and cost for a single workload. Most of the benchmarks I saw are throughput-only.

- Some explanation of the “patented 1PC protocol.” Your website [1] suggests that you treat single EBS volumes as high-durability, replicated storage, which seems unusual to me - apart from io2 volumes, EBS is designed for less than 3 nines of durability [2].

[1]: http://www.eloqdata.com/blog/2025/07/15/data-substrate-detai...

[2]: https://aws.amazon.com/ebs/features/

I'm no expert in corporate finance, but whether or not OpenAI goes bankrupt feels like the wrong question to me (in thinking about this loan). Wouldn't a bank be more concerned with (1) the likelihood that OpenAI can raise another round of financing from which to repay the bank, and (2) the likelihood that OpenAI will have assets worth >10B when/if they do eventually declare bankruptcy?

The bank's risk seems quite a bit lower than the VC's risk.

TFA goes into this in some depth: there's an option to subscribe for one month with a one-time payment. After the month is up, your account automatically reverts to the free plan and you get an email with your fonts attached.

I’ve been exploring porcupine lately too - the visualizations are especially useful when debugging. It pairs exceptionally well with any DST setup.

Thanks for the great tools, Anish!

git-spice does everything I liked from Graphite, but it’s fully open source and easy to adopt piecemeal.

https://abhinav.github.io/git-spice/

No, it was S3 becoming strongly consistent in 2020: https://www.infoq.com/news/2020/12/aws-s3-strong-consistency...

This is especially interesting because Multigres is being led by Sugu Sougoumarane, one of the Vitess co-creators and Planetscale co-founders - so the two projects are growing from the same soil, so to speak.

https://youtu.be/28q9mFh87KY?si=SK3f1OEApWRlcr83

Full agreement from me that jitter is essential. Here’s AWS on good retry policies: https://aws.amazon.com/builders-library/timeouts-retries-and...

Earthly has pivoted away from their CI/CD products: they’re shutting down Satellite, and they’re stopping active maintenance of the Earthly open source project.

https://earthly.dev/blog/shutting-down-earthfiles-cloud/