HN user

zachmu

919 karma
Posts15
Comments259
View on HN

I remember that engineering decision. You guys were pretty early customers for your throughput and durability requirements (we hadn't even added standby replication yet when you started your integration). We've come a long way in the years since then.

Neon is basically this same idea: postgres on a copy-on-write file system.

These aren't really "branches" though, they're hard forks. You can't merge them back after making changes. Dolt is still the only SQL database with branch and merge.

Regardless of whether this particular project goes anywhere, it's at least very interesting that Yegge has discovered a way to make multi-agent setups work better. Giving them discrete personas ("you are a senior database engineer with 30 years of experience") and narrower scopes makes them much more effective. This was surprising to me but makes a lot of sense in retrospect.

We build DoltDB, which is a version-controlled SQL database. Recently we've been working with customers doing exactly this, giving an AI agent access to their database. You give the agent its own branch / clone of the prod DB to work on, then merge their changes back to main after review if everything looks good. This requires running Dolt / Doltgres as your database server instead of MySQL / Postgres, of course. But it's free and open source, give it a shot.

https://github.com/dolthub/dolt

when I was learning Go, I read a guide that told you to fire off a goroutine to walk a tree and send the values back to the main goroutine via a channel. I think about that "just an example" guide a lot when I see bad channel code.

For me the biggest red flag is somebody using a channel as part of an exported library function signature, either as a param or a return value. Almost never the right call.

Think of it as a replacement for spanner with a postgres frontend. It's about global availability and replication without application-level sharding.

Sometimes it's a reasonable choice to pay for software, especially if you're a large company that can easily afford it. It's not like "just using postgres" in a manner similar to Cockroach's capabilities is trivial, building your own solution also has a whole set of risks.

If you're absolutely opposed to ever paying for a software solution, then sure, avoid commercial projects. I'm happy to spend my (company's) money on useful software.

The BSL doesn't make it closed source, it prevents a competitor from running their own DBaaS business using Cockroach as the backend. This has happened to various open source projects, AWS started selling their technology and ate their lunch.

BSL is a totally fair compromise for commercial open source licensing imho.

If you see BSL as the first step to an announcement like today's, that's a fair criticism. Not sure how often that happens. But BSL doesn't disqualify software from being open source.

Seems like this spells the end of any website that vends information or answers to questions, as opposed to narratives. Narrative based writing (or images) will be fine, people will still visit and see ads. But anything matching the search term "how do I" or "when was the" is toast.

Most websites in this business are, generously, hot garbage. And it's getting worse. So I imagine AI search will be quite successful at displacing them.

The problem moving forward: how do we keep information-based websites in business so that AI can scrape them? There's a real risk of AI eating its own seed corn here. Seems only fair that AI scrapers pay for the content since they're not generating ad views (and are in fact stealing future ad views). But I have no idea how you would enforce that.

This is true, you can just return the method without invoking it.

I don't tend to use that convention though, because most of the time when I use this pattern, I'm returning a function that uses a parameter I pass in. You can see this in the predicate example. I prefer keeping my call sites consistent and always using functions that return a function when invoked, rather than sometimes invoking them and sometimes just passing the func reference. YMMV.

People always cite exclusivity deals / monopoly power when it comes to Ticketmaster's dominance, but I also recall reading post-mortems about several failed competitors that indicate the problem Ticketmaster solves (massive spikey demand with strict guarantees on the seats selected) is quite technically challenging. I know, it doesn't seem like it would be that hard to solve, you're probably already thinking how you would do it. But you can't ignore that many others have tried and failed.

The Oasis is a great device with one fatal flaw: battery life. For some reason they nerfed the battery relative to the paperwhite so it lasts about a week instead of about a month. Probably won't bother a lot of people but it really bothered me. I read a lot and hate having to think about recharging.

I ended up with the Kobo Libra 2, which has all the same features as the Oasis but also has a month-long battery. I love it overall, great little device. Includes some quality of life features beyond the Oasis, including auto color tone shifting of the front-light in the evening (cool to warm), being able to adjust the light by swiping up the left side of the screen, and more options for progress indicators / headers and footers than the kindle has.

Kobo changes their lineup constantly, which means the Libra 2 has been replaced with a more expensive color version I haven't tried. Color on an e-ink screen is not an interesting feature to me, esp. not when it makes the device more expensive.