As expected, I didn't have much access to electricity in the first two weeks of march. Things are getting back on track now.
I put a bunch more work into the internal consistency article.
- Rewrote the description of internal consistency and much of the conclusion.
- After a back and forth with one of the noria authors, I realised that my first failure class was conflating several different problems. That's been teased out into two classes now, both with better examples, and a note about the connection to handling joins on out-of-order data.
- After teasing out that extra failure class, I grew some doubts about how flink and spark structured streaming handle it. I talked to an ex-Flink developer who asked around and concluded that it probably doesn't, so that's been added to the list of things to repro.
- For the kafka streams repro, I'm still failing to produce any output at all from the left join example that ships with kafka streams. A helpful person on the confluent slack suggested trying a different repo with examples that they actually test before shipping :S
So the main remaining todos are:
- get repros for all kafka streams failures
- try to repro flink early emission failure
- study spark structured streaming closer to see if I've been too generous
- clean up the 'inconsistent rejections' example
This ended up being a much bigger project than I had intended, but I'm feeling pretty good about the results
I have no idea what kind of things people are paying me money for. If you email me and tell me ... I might still not do those things, but at least it won't be because I assume that everyone wants more long posts about consistency models instead :)
Other new stuff:
- (public) How safe is zig? Prompted by reading a bunch of recent discussions where most people equate it with c, and one persistent HN commenter has some weird motte-and-bailey argument about it being as safe as rust. Seemed like it would be useful to clear that up.
- (public) Notes on Bullshit jobs, Debt and Utopia of rules.
Kevin's post on porting a rust program to zig made the rounds last week.
The comments reminded me how bad voting is as a mechanism for surfacing good information. For example, the most highly-voted suggestion on both r/programming and r/rust introduces a virtual function call per pin set, a painfully expensive operation on a 64 MHz arm chip. Whereas the suggestion with much less code and no overhead ended up near the bottom of the page.
Not to mention the rust mailing list concluding that the zig version was nicer only because the zig mmio library has homogenous types, which is an impressive misreading given that half of the article is devoted to explaining how the zig version deals with the heterogenous types. As it happens, both versions of the api are near-identical because they're both generated from the same xml file.
But apparently a wave of new people showed up in the zig community shortly after, so at least some people found it compelling.
I spent the first two months of this year working on a pinebook pro, a $200 arm laptop. It was a surprisingly good experience.
I stuck with manjaro for the base system, since it seems to have the latest drivers, and used nix to install everything else. Almost all of my regular tools worked out of the box (nixops wouldn't build and rr doesn't support older arm cpus).
I typically got 6-10 hours battery life. The frame feels solid. The screen is fine, if a little dim. The keyboard feels great but has terrible rollover (eg can't send caps-shift-letter). The touchpad is garbage, verging on unusable even after firmware patches.
Heavy websites like slack were a drag, but day-to-day coding was fine.
I wouldn't recommend buying one right now, but if they can improve the touchpad and keyboard in the next generation then it might make a solid travel laptop.
I recently reread some of the early design docs for trio. They're one of my favourite examples of taking a tangled problem space and reducing it to its essence: