azurelake

You have to understand that Broadcom isn't actually Broadcom the chipmaker. It's a private equity firm that used be named Avago Technologies before it bought Broadcom. So squeezing until there's nothing left is the plan.

https://digitstodollars.com/2022/06/15/what-has-broadcom-bec...

> Put another way, automated tests don’t go far enough. We need yet another higher layer of abstraction. Computers are better at deciding what tests to run and when, and are also better at interpreting the results.

Sounds like you might be interested in https://antithesis.com/ (no affiliation).

MySQL has a very mature open source HA story with the flavors of group replication, as well as being able to replicate DDL. Not to mention Orchestrator and friends.

As a matter of fact, EnterpriseDB (the largest contributor to Postgres) has a paid multi master offering, so there's anti incentives in place to improve its HA story...

You can also add add GSIs (with their caveats) without any re-work.

Your second sentence is more on the right path (speaking for myself at least). It's about labeling and observing the literal physiological sensation that is occurring in your body and choosing how to react vs. identifying strongly with the current emotion and reacting.

Easier said than done, of course!

I’d be curious to hear more detail about the FoundationDB data loss issue that you saw? Do you remember what version / what year that you saw it?

Elixir is in the process of adding a gradual type system right now FWIW.

One of the best articles I've seen on here this year! I didn't know about the existence of `pg_hint_plan`.

> Define "actual experiences".

People without aphantasia literally count sheep to go to sleep.

Same. I would pay 50 / month for an Elixir plugin that had a comparable amount of polish to RubyMine.

My argument against wrapping for backend services is that is:

1. I think that it is preferable to handle the error where it happened instead of at the top of the stack. For a backend service, there's really only three things you want to do with an error: log it, maybe bump some metrics, and return an error code and ID to the client. You have a lot more information available (including a stack trace if desired) if you handle it at this point.

2. By wrapping the error up the call stack, you're building an ad hoc stack trace. Performance wise, this is (probably, haven't measured) a lot better than an actual stack trace, but as you said yourself, the top concern is debug-ability and developer velocity.

3. Wrapping an error doesn't provide just a stack though, you can add values to the error! Except...what does that really buy you vs. just adding the values to your structured logging system going down the stack vs. doing it on the way back up in an ad-hoc way? Those wrapped error values are a lot more difficult to work with in Grafana vs. searching based on fields.

4. If I have a stack trace, structured log fields, and a correlation ID, I personally don't get any value out of messages like ("could not open file), as I can just use the stack trace to go look at exactly what the line of code is doing. You could argue that with good enough wrapping, looking at the code wouldn't even be necessary, but I think that's pretty rare in practice. It also seems like a lot of extra work to spend a minute loading up the code in an IDE.

5. As mentioned in 1), what the client gets is just an error code and trace ID anyways. In fact, we actively don't want the wrapped context to be sent back to the client since it can be a security concern. If that's the case, we need to remove it and log it anyways. Why not just log the information in the first place?

Anyways, curious to hear your thoughts. I used to advocate for wrapping errors, FWIW.

Thank you!

Curious what the gem is?

Can’t wait!

I’m curious if you’re willing and able to share: Are you using FoundationDB as the data store for Antithesis?

Vector clocks give a partial ordering. FDB version stamps give a total ordering by having a single process issue them for the entire cluster. There's a good breakdown here: https://blog.the-pans.com/notes-on-the-foundationdb-paper/

That's more or less what Kafka is.

Probably not too much to say that’s specific to FLAME. Closures are serializable and can be sent as messages to actors on the BEAM with a few caveats.

From a quick look at the code, this looks the magic line: https://github.com/phoenixframework/flame/blob/main/lib/flam...

They do, look up the “Backend for Frontend” pattern.

> You can't combine two indexes to filter on two cols; you need one composite index

Can you expand on how you perceive traditional RDMSs to be different for this case?

The difference is that Gates is an industrialist who does acts of philanthropy. MrBeast does acts of philanthropy to be an industrialist.

You’re not wrong, but there’s a big difference between donating money to feel good about yourself or even hope others like you more, and building a capital engine with a veneer of philanthropic paint.

Totalitarianism is much different because ultimately some human is making all the decisions on the allocation of capital. The uncomfortableness that the parent is describing isn’t with the power disparity, it’s with the fact that our world is increasingly controlled by paperclip maximizers.

The UX of the notification case could be reasonably solved by either having the notification being send as the last step, or sending a notification that they were removed with the reason if that’s not possible.

What did the API of the meeting service look like specifically?

I disagree, and here's why. There are basically two reasons a cancellation step would fail.

1. A misunderstanding of the business rules. In the flight example, you thought that were flights were cancellable, but actually the airline only offers nonrefundable seats.

2. System type errors, e.g. network outages.

If you get a type 1 failure, that's an error that gets ingested in your error monitoring service, and is a bug that needs to be fixed. If you get a type 2 failure, idempotent cancellation (which is necessary for this work) will eventually get you to your desired state. Either way, you shouldn't need to model deeper into the state graph.

There's nothing to debug because a failure during a saga is a totally reasonable and expected thing to happen. Take the example in the article.

1. You book a flight. You successfully reserve a seat.

2. You book a car. You successfully reserve a sedan.

3. You try to book a hotel room. The room that you wanted was booked while you were booking your flight, and there aren't any more available.

You obviously don't want the car or flight anymore, and you want to cancel them without a human having to manually fix it.

Nope, it's not a toy. It's a fork of Uber's workflow engine, Cadence.

You don't need to explicitly interact with an event queue because it's a higher level abstraction that sits on a queue. In fact, that’s the big value add.

ACID doesn't help you once you're trying to coordinate actions across systems, like the example in the article.

I would go so far as to guess that the entire reason the piece exists is to be a commentary on the arbitrariness of important art, and that the real art intended was creating a situation where someone who isn’t an insider gets to decide what’s important.

MySQL is still ahead operationally (no vacuum, group replication, gh-ost, optimizer hints, etc.). I would choose it unless one of the Postgres extensions is a killer fit for your project.

Just FYI if you didn’t already know this:

  Any transaction which is run at a transaction isolation   level other than SERIALIZABLE will not be affected by SSI. If you want to enforce business rules through SSI, all transactions should be run at the SERIALIZABLE transaction isolation level, and that should probably be set as the default.

Given that running everything at SERIALIZABLE probably isn’t practical for you, I think it’s more clear code wise to use explicit locks. That way, you can grep for what queries are related synchronization wise, vs. SERIALIZABLE being implicit.