@dang title has been changed to "The (successful) end of the kernel Rust experiment", since there were complaints in the articles comments from the committee members that that was a sensationalization of what actually happened.
anecdotally, i had a professor (if you're reading this, hi) who would wink in conversation at exactly the right point to add a little "isn't the world a funny place" comedy to whatever he was saying... wasn't clear if intentional or a tic for when he thought he had said something clever. I noticed that habit to have transferred to me for a while after, though I think now it's faded.
that'd cause an org wide panic, and you might lose key personel in your actually profitable business units. cutting costs at this scale is not just reducing employees, it's getting rid of employees who are working in areas you need to cut. the secrecy lets management retain control.
my experience with python's optional type system was that the simple stuff works very well, but when you try to go down a type rabbit hole for more advanced stuff involving generics it becomes really unworkable, inconsistent, and hard to dig yourself out of.
but for little things, like just function signatures, it's great!
like them or not, analogies are one of the pillars of the American legal system. Being able to reason about them and create them (usually with motivated reasoning) is a highly valuable skill.
For those unaware, in a legal case where there is no precedant (something us technologists encounter often), you make the case that what you are doing is just like what X had done, and should be treated in kind.
scottlamb seemed to be implying it's not worth being able to since it's an uncommon use case, so I was explaining why even if it's uncommon it's must-have.
I took 6.824 under Paxos (I think we took it at the same time maybe? not sure if you were TA at that point) and then helped a friend when it switched to raft and good lord that seemed to be a worse for them.
my point is that these are the fat tail + survivor bias of cases where you do actually care about performance to this degree, so it probably is actually more common in practice when you're looking into it.
even though precise control is the exception, if you can't do it, you can't use your language in a lot of critical contexts (and end up linking C, Zig, Rust, etc).
it's very likely that it's one of the cases that when reducing cache misses does really matter it's very different from using as little space as possible, and the degree to which it matter dwarfs the degree to which it's not a frequent concern (i.e. fat tail).
for example, if I have a struct that contains a bunch of atomic fields, I may actually want to control the layout to ensure they are far apart (even inserting padding) to prevent e.g. false sharing https://en.wikipedia.org/wiki/False_sharing.
I think it does way too much "all in one shot" v.s. a layered abstraction approach you have to do with Paxos where you build up from the basics of consensus.
The evidence that raft is more "understandable" rest on IIRC a multiple choice question test not on actually implementing the thing working correctly. But (without having seen the test, but being familiar with both algorithms) it is easier to answer questions about what raft is supposed to be doing than paxos, but paxos actually confronts you with the edge cases more explicitly that are still present in raft.
Granted, both are hard to implement correctly! I just think that learning Paxos does lead to a more detailed understanding of consensus than raft.
This is because Google Scholar treats PDFs as first class citizen, so your Important blog posts can get added to academia.
maybe a plugin can solve this particular gripe...