partiallattice

That's an SLA where they expect to end up paying customers back for outages. They've done an admirable job with only a few global outages, but subsets of customers have experienced plenty of outages.

A single 5 min outage would blow through more than a decade of SLO at 6 9s. As far as I'm aware, there does not exist a service that has been up for more than a decade with fewer than 5 min of downtime, and that definitely includes route 53.

> RonDB provides Class 6 Availability, meaning its system is operational 99.9999% of the time, thus no more than 30 seconds of downtime per year. This ensures that RonDB is always available.

I get marketers stretch the truth all the time, but they can't possibly be serious.

One tough thing about rule of zero classes is that many to most end up having an implicit 'the object has not been moved from' precondition on methods. The classic example is a class with a unique_ptr member that is never null except after move, so none of the methods have null checks.

I understand why the committee was unable to get destructive moves into the standard, but I do think that is one thing Rust got right that I really wish C++ had.

Most of the time, sure, but there are lots of cases where `defer` being function scoped leads to manual unlocks, e.g. inside loops or short critical sections in the middle of a function. Yes, you can use closures/otherwise, but few codebases are that disciplined. Those edge cases are plentiful enough that catching panics is dangerous.

Especially since caught panics amount to exceptions and most Golang code isn't exception safe. It's a recipe for leaking database connections, deadlocks, etc.

Small typo:

it can be called with an S as the single argument and produces something of the type Step parametrized with S and A) and -does not- outlives the s lifetime.

's refers to a minimal lifetime and not a maximal limit.

Even still, that's only 100k jobs. There's already more than 4 million jobs in the city alone. A 2.5% increase in jobs is just not going to change that much. Cyclical employment changes alone are much, much larger than that.

So much this. Every time I want to make a function async, I have to write my 5010th `ErrorOr` struct to send over a channel. Even if they would only add the multiple return hack to channels, that would save me a bunch of pain.

> The author seems to be confusing typeclass composition with OOP.

I agree and would like to expound on that idea. One of my biggest frustrations with inheritance in traditional statically typed languages (I program in C++ for a living) is that inheritance is performing two functions at once: code reuse and typing. Confusing the two seems to cause a lot of pain. Inheritance as a type system is describing the kinds of things the object can do. Inheritance is (usually) a sufficient condition to say that the types can be used interchangeably. Making inheritance the only way to express the type information often forces some very unfortunate code.

The author is trying to use traits as a code re-use mechanism. He wants the trait to be able to see into the implementation and be a function of the implementation's private data. If that were allowed, that would invite all of the pain of inheritance for that kind of trait. Types with a different internal implementation would end up being awkward at best.

> > What IS the idiomatic Rust way to do a cyclical directed graph?

> Unfortunately, the correct idiomatic way is that you try very hard to avoid doing so. Rust is all about clear ownership, and it doesn't like circular references.

> The usual solution is to put the cyclic graph code into a library, and to use pointers and about 20 lines of unsafe code.

The point about C++ is important. Cyclic graphs are hard in any non-GC'ed language because it breaks the ownership story.