zadikian

no profile record

comments

10 ngày trướcdiscuss

The part about durable workflows is technically correct, but it's focusing on different things than what I've ever run into in practice. Any mildly complex system will have side effects outside your DB, then you want idempotency. If you have no side effects, you probably don't need a durable workflow in the first place? Maybe there's a more concrete example.

I have rolled my own little durable workflows in Postgres before, in fact before I even knew durable workflows were a thing with solutions like Temporal. That's fine for many cases where you aren't doing enough steps for it to be tedious, and/or you want permanent records. Would do it again, but not for atomicity reasons.

Other comments have already discussed the issue with the outbox UDF, your external system has to poll and retry either way. It works though. Maybe I'm misunderstanding this?

10 ngày trướcdiscuss

So the author made a Rust to C transpiler and immediately used it to transpile... the Rust compiler. I love it.

20 ngày trướcdiscuss

They have an AAAA for v6 as of right now, but it wasn't always there https://www.nslookup.io/domains/news.ycombinator.com/dns-rec...

21 ngày trướcdiscuss

Almost all mobile carriers use v6, but not exclusively. They also hand out a v4 to every customer. The v6-only part is their internal network.

21 ngày trướcdiscuss

The saying is you build better abstractions if you don't build them too early.

21 ngày trướcdiscuss

Yep. Keyword "tried," as in they did it for a while then hit a point where it's impossible to faithfully follow the abstractions because they're wrong.

21 ngày trướcdiscuss

I always felt like I abstract and modularize things way less eagerly than other programmers. Was pleasantly surprised to find that LLMs do it mostly my way by default, then again they're also bad at abstracting when it's actually needed.

21 ngày trướcdiscuss

Not necessarily. I've gone down this rabbit hole in another thread, tldr there are alternatives that would've been easier initially but with the downside of leaving the routes fragmented.

24 ngày trướcdiscuss

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

tháng trướcdiscuss

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

tháng trướcdiscuss

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.

tháng trướcdiscuss

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

tháng trướcdiscuss

> 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.

tháng trướcdiscuss

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

tháng trướcdiscuss

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.

tháng trướcdiscuss

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.

tháng trướcdiscuss

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.

2 tháng trướcdiscuss

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.

2 tháng trướcdiscuss

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.

2 tháng trướcdiscuss

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