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?
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.)
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.
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.
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.
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.
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#.
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].
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.