Hacker News: zadikian

New comment by zadikian in "I hate compilers"

zadikian — Thu, 18 Jun 2026 19:43:43 +0000

I agree, also making it do useful work could detract from how well it works as bot-prevention. Recaptcha suffered from its own success eventually, having to ask people to read nearly impossible things, and now many sites are instead asking me to solve puzzles with no practical use.

P.S. Great to see you, omoikane

New comment by zadikian in "PgDog is funded and coming to a database near you"

zadikian — Thu, 11 Jun 2026 02:55:44 +0000

This is exciting. INSERT (SELECT ...) doesn't work though, right? The docs only mention VALUES inserts.

New comment by zadikian in "Do we fear the serializable isolation level more than we fear subtle bugs (2024)"

zadikian — Tue, 09 Jun 2026 23:14:50 +0000

The "transaction safety" part is confusing. What they mean is if you use SERIALIZABLE, transactions need to be retried, so your code inside the xact should be idempotent. I guess this is safer in Haskell because there are no variables, but that doesn't stop your code from having other side effects.

New comment by zadikian in "Do we fear the serializable isolation level more than we fear subtle bugs (2024)"

zadikian — Mon, 08 Jun 2026 15:22:56 +0000

Oh I misremembered, yeah just tested and the second INSERT errors.

New comment by zadikian in "Do we fear the serializable isolation level more than we fear subtle bugs (2024)"

zadikian — Mon, 08 Jun 2026 07:49:45 +0000

> TBH I think I've seen more database use than not specifically because it serves as the central race-resolver in a system

But you usually don't need serializable for this, cause READ COMMITTED locks the rows during updates.

New comment by zadikian in "Do we fear the serializable isolation level more than we fear subtle bugs (2024)"

zadikian — Mon, 08 Jun 2026 06:18:22 +0000

Cause I want relations and SQL. But also I kinda get what you mean and would not use serializable in Postgres.

New comment by zadikian in "Do we fear the serializable isolation level more than we fear subtle bugs (2024)"

zadikian — Mon, 08 Jun 2026 00:16:27 +0000

In my experience, the performance hit is so bad that it's not feasible to use that way. It's also not strictly safer behavior-wise because retries can trip people up.

New comment by zadikian in "Do we fear the serializable isolation level more than we fear subtle bugs (2024)"

zadikian — Mon, 08 Jun 2026 00:15:22 +0000

Tbh I always forget the specifics soon after reading them. Basically you can do an atomic UPDATE WHERE if there are no subqueries involved. 90% of the time that's good enough, and for anything else I end up refreshing on features like SELECT FOR UPDATE.

Well also I know Postgres UNIQUE indexes provide additional locking. Like you can do an INSERT... WHERE NOT EXISTS or INSERT... ON CONFLICT that is guaranteed to succeed.

New comment by zadikian in "Do we fear the serializable isolation level more than we fear subtle bugs (2024)"

zadikian — Sun, 07 Jun 2026 23:31:21 +0000

Was curious about the Flexcoin hack, but the article wasn't loading, so here's an archive: https://web.archive.org/web/20240423000007/https://hackingdi... Supposedly it was this simple:

  mybalance = database.read("account-number")
  newbalance = mybalance - amount
  database.write("account-number", newbalance)
  dispense_cash(amount)   // or send bitcoins to customer

and MongoDB didn't even have a way to do this atomically? An RDBMS with read-committed would handle this fine if you did "read for update" on that row.

New comment by zadikian in "LLMs Are Not a Higher Level of Abstraction"

zadikian — Mon, 04 May 2026 22:32:26 +0000

Even if it were reproducible, realistically most people are using some service like Claude that makes no guarantee that the model or hardware didn't change. Which is fine, it doesn't need reproducibility.

This is interesting though, I didn't know PyTorch had a debug mode for reproducibility.

New comment by zadikian in "LLMs Are Not a Higher Level of Abstraction"

zadikian — Mon, 04 May 2026 20:28:39 +0000

This is sorta how I've felt working the past ~7 years.

Simple example, we've been striving for 90% unit test coverage and thorough code review when there's 0% integration test coverage. I blame the metrics only looking at unit tests, but also many people think unit tests should come first. I would prioritize integration. There are some small pieces that need to work reliably, but if your system relies so hard on all of them working right, it's a bad system. That, and too many things will work in pieces but not overall.

Broadly I'm gonna assume that the team will later hire solid SWEs who don't necessarily know how our stuff works, and aren't going to read 100 docs about it. If this is a backend+DB combo, get your DB right and there won't be too many wrong ways to code against it in the future, get it wrong and it becomes a black hole for SWE-time. Or if someone on their first day can't run a system locally for debugging, no matter how elegant the code is, don't count on that system getting fixed quickly during an outage.

New comment by zadikian in "Why IPv6 is so complicated"

zadikian — Mon, 04 May 2026 04:20:30 +0000

Want to add, it's not too late to do this on top of the ipv6 we have today.

New comment by zadikian in "LLMs Are Not a Higher Level of Abstraction"

zadikian — Mon, 04 May 2026 04:18:36 +0000

If you throw away the code then yeah, but I've never seen anyone do this.

New comment by zadikian in "Why IPv6 is so complicated"

zadikian — Mon, 04 May 2026 04:10:05 +0000

The home solution is supposed to be mDNS. I just checked right now, my mDNS isn't working on my LAN, idk why.

New comment by zadikian in "LLMs Are Not a Higher Level of Abstraction"

zadikian — Mon, 04 May 2026 00:53:45 +0000

I'm fine with that. The part that makes it not really an abstraction is, you still deliver code in the end. It'd be different if your deliverable were prompt+conversation, and the code were merely an intermediate build artifact. Usually people throw away the convo. Some have tried making markdown files the deliverable instead, so far that doesn't really work.

It makes even less sense when people compare an LLM to a compiler. Imagine making a pull request that's just adding a binary because you threw the source code away.

New comment by zadikian in "Why IPv6 is so complicated"

zadikian — Sun, 03 May 2026 18:58:38 +0000

Yeah, so you still reach the user, it's just probably less efficient than the all-v6 route.

Edit: Oh, you mean if they want unsolicited inbound traffic? Sure, but that's only a thing for services. I mean you can have a default-allow firewall to home devices but really shouldn't.

New comment by zadikian in "Why IPv6 is so complicated"

zadikian — Sun, 03 May 2026 18:54:30 +0000

That's a legit concern. If that's not interesting enough to the kind of user that wants all-new v6, instead start from today where some users are on the new v6 network, and say they added the 4:: prefix as a way to pick up the kind of user that doesn't want to change much. They'd still be compatible eventually. Though the reason I was thinking 4:: from the start would've been attractive enough is, a lot of people did use 6to4 and other halfway measures despite having no immediate gain.

Today's DNS6 DHCP6 etc are totally incompatible with v4. 4:: buys backwards-compatibility. Each can be updated to support longer addrs without caring whether you use it with v4 or v6.

New comment by zadikian in "Why IPv6 is so complicated"

zadikian — Sun, 03 May 2026 16:59:17 +0000

I mentioned 6to4 in the original comment. It doesn't fulfill this use case, it still relies on v4 packets.

New comment by zadikian in "Why IPv6 is so complicated"

zadikian — Sun, 03 May 2026 16:58:19 +0000

Owning 192.0.2.4 in v4 didn't really give you 2002:192.0.2.4 in v6, as in v6 packets can't reach you that way. If someone sent a v6 packet there, some router on their side would intercept it and relay as v4. Aside from this still relying on v4, it was very unreliable in practice because of uncertainty around what v6 route is taken to the relay. There's an RFC somewhere that looked at this in hindsight.

New comment by zadikian in "Why IPv6 is so complicated"

zadikian — Sun, 03 May 2026 15:40:10 +0000

If you want to start using v6 before you're sure that every host supports it. But this isn't strictly needed, could just rely on something in DNS telling you the host supports it (I'm not saying AAAA records cause idk if you'd use them in this scheme).