jlrubin

one thing i've found, is that i've regretted not blogging more via PDFs.

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

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

Options like std::discrete_distribution don't allow updates, in Rust e.g. https://docs.rs/rand_distr/latest/rand_distr/weighted/struct... allows updates but sampling is O(log n) and updating is also O(log n).

This neat data structure has a great set of tradeoffs.

The fraction turned out to be approximately 69%, making the graphs neither common nor rare.

The wording kinda bothers me... Either 31% or 69% is exceedingly common.

Rare would be asymptotically few, or constant but smaller than e.g. 1 in 2^256.

I guess the article covers it's working definition of common, ever so briefly:

that if you randomly select a graph from a large bucket of possibilities, you can practically guarantee it to be an optimal expander.

So it's not a reliable property, either way.

i have the unique experience of being in a plane over the Bering sea a few hours ago. https://twitter.com/JeremyRubin/status/1789273537179426922

i was going nuts in my seat and seemed to be the only one on the plane aware of what was going on.

wouldn't those be a different category & thus get unique coverage?

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.

money = money(t)

inflation = d money / dt

rate of increase of inflation = d^2 money / dt^2

rate of change in rate of increase of inflation = d^3 money / dt^3

rate of increase of inflation was decreasing = sign(d^3 money / dt^3)

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.

fwiw i was able to successfully port this complex project into rust's type system.

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!

note that it is measured in SLOC.

You can do in 500 lines of rust what might take 5000 lines of C.

I would be interested to see this as a stack chart showing overall LoC.

The free market is usually better at allocating resources than the government.

Plus, the government already has much more than $125M it could use to fund AI research, why do we need to take away Schmidt's funds to do so?

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.

you got it flipped. Dependendent types enable you to do things like "takes a nonempty list" and "returns a nonempty list of greater size".

Linear types lets you do things like "this data can only be written to a file once".

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.

Hi back atcha!

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 dont like raft personally.

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.

just my 2¢ and no one asked ;)

drumroll please

yup!

thanks so much! your support means a lot :)

i'm assuming she purchased what she thought was percocet and it was actually fentanyl, not that she mixed up her pills

I think that Julia lacks a native tagged enum, which is what rust has. Unions are more akin to a local trait T that you box and implement for all the return types, which is strictly worse. If instead explicit unions were optimized to be tagged enums you could get the big performance gains of rust.

Calling code would, of course, have to destructure the return. But destructures of a return value can be very efficient using match (jump tables internally where possible).

i think you can successfully type the return type using a Union. This might have the performance penalty of instability, but i care more about the soundness issue of potentially returning garbage types than about e.g. vtables

btw rust-miniscript is a nice example of a type stable parser :)

it has a huge impact on static analysis to know that the type is a Box<dyn T> in rust, and you can't (without something else) downcast Box<dyn T> to a specific U.

i don't care about the performance as much the correctness :)

this has always been my top complaint about Julia -- programming without type stability is madness!

nicely done jj!

looks like bitcoin/lightning iaps coming to ios soon :)

https://en.wikipedia.org/wiki/Toyota_RAV4_EV