Thinking yet again wistfully of how great vlang.io could be if they had just made `Result<T,E>` a normal thing in the standard library instead of... the amazingly unusual (and untyped) thing that they did.

So many other choices in that language are very, very right.

Today is a supermigraine day for no obvious reason and I long to be free of the absurd failablity of meat

Gpt-4 *was* trained in a week.

A new Git version just dropped and it comes with a new experimental `history` command!

`reword` can be used to change commit messages and `split` can untangle a single commit into multiple ones.

No more interactive rebase. 🎉

github.blog/open-source/...

I think at this point I'm honestly hoping the dprint folks just declare war and make a completely alternative rust formatter.

dprint's other formatters all have very sane core decisions -- namely, focusing heavily towards stable hysteresis, avoiding reflows across linebreaks without reason -- 😌💙

I'd also really love for `imports_layout = "Vertical"` to be fully supported, because that would result in a lot more legible/confined diffs in import lines, but that's been in "unstable" land for heavens knows how long... 👴⌛

Yeah 😭 I haven't actually debugged every path in the decision trees there, I've just noticed editors and tools on my different computers having Different Opinions that made diffs flap... and I've started putting edition explicitly in my rustfmt.toml files and that's made it a little less bad... 🫠

...and I think it's useful to separate those two types of domains: like, yeah, totally, use CRDTs for live editors where individual events are so small that if they're not applied rapidly they lose semantic attachment anyway.

Bigger changes? Can be (unintuitively) *easier* to manage in other ways.

clarification: I'm treating {live collaborative text editors} as a separate beast from {two different programs are trying to apply an edit to a markdown file's frontmatter}, here.

The former does *not* have what I'd call distinguishable edits. But patching named fields: more so.

"If edits are distinguishable, one can just retry patching until it works" sounds kind of crazypants, but I think it's theoretically sound (depending how hard you lean into "distinguishable"), and afaict it's definitely *practically* sound.

E.g. I have Obsidian and other processes interact... fine.

The filesystem _is_ terrible at handling concurrent writes. There's no Compare-And-Swap atomic. Only atomic writes (with careful use of posix renames). This suuuux.

Buuuut. CAS is the weapon you need for counting. If edits are distinguishable, one can just retry patching until it works.

I think you're fully into productive nuance land here :D

Some observations on git: yeah, ultimately it does need a mutex, if you tried to sync it by filesystem alone. It's a remarkably small one though: really its just the heads+tags files. I think there's something very useful there.

I'm a lot *more* frustrated by how features and fixes get locked behind "nightly" for 7+ years, and how rustfmt's choices generally have no respect for user intent or hysteresis of change and are overly-line-length-sensitive diffchurn factories.

But saying it doesn't change across versions is laugh

"style_edition" can be "2015", "2018", "2021", or "2024". It's probably inferred from "edition". There's also a (depreciated, but nonetheless) "version" which can be "One" or "Two". "edition"/"style_edition" have defaults but may also be inferred from toml files; Rustfmt and cargo fmt differ in how.

I have the absolute opposite of interest in actively seeking out more pain, but just at a glance I notice that rustfmt's own docs mention no less than four different "editions" of behavior, which can be controlled by three different settings as well as inferred from several different files. 🤷

Beware the Wabe, especially if you should choose to gimble.

It is truly incredible to say that Rustfmt might almost single-handedly make Rust a nonviable place for me, and yet it's... true.

The diff churn that Rustfmt makes literally drives me to distraction.

Rust is only a tolerable programming language as long as I *literally* don't have to look at it.

Rustfmt is insane and must be replaced.

Behavior changes across versions; features and fixes get locked behind "nightly" for 7+ years; it has no respect for user intent or hysteresis of change; ...

People who say “there is no algorithm here” are misinformed on 2 counts

- There are 50K+ of algorithms designed by developers and non-developers alike

- There is no singular “here”, there are many interconnected places

Your posts enter a new kind of internet and show up in places you don’t know.

A hybrid architecture with both files and indexes means the application has to define how to detect file changes and maintain the indexes.

But that's doable.

And, that investment of effort also means that global mutexes disappear. Which is a lovely "bonus".

But there's hybrid options here, too.

For example, @obsidian.md indexes things into an SQLite db... But it builds the index *from* files. Rather than exporting files. Works wonderfully.

Still files-first -- easy legibility + interop. Also has a db for fast queries. Win/win.

Frame from the video linked in the post, showing a slide about "levels of agency", and a list of techniques in increasing order of power. "Export to common formats" is the weakest; "continuous export" is in the middle; "bi-directional sync" is most preferred.

Found the video for that talk: m.youtube.com/watch?v=VCT4...

The whole thing is worth watching front to back, but it really starts cooking on this particular detail around 12m12s in.

Personally, no -- because it doesn't diff or play nice with other sync + needs a complete global mutex.

Sibling comment bsky.app/profile/mast... kinda nails it: if all you can do is backup, it's a dead end.

@jessmart.in also gave a stellar talk abt this: app-2025.localfirstconf.com/schedule/tal...

In theory yes, in practice...

Istm if people lead with doing the sync part first, they tend to get complicated-CDRT-brained and then very rarely actually circle back to making sure data at rest is in legible files. 💁

There's examples where both coexist, but afaik they always started w files.

This in turn is why the half of the local-first community I'm most interested in is the "files-first" fragment.

If I can't make sense of and easily use the data at rest, with *no* sync service... What are we even doing.

Sync needs to be subservient to first having legible data.

“Anyone can fork” is technically true but economically misleading — you can’t fork an operating budget.

Code is free. Infra and labor are not.

👀👀👀

Pleasepleaseplease to make sure you document what your slugify function is. :) This is a very awesome feature and I'm glad for it. But also minor drift between defn's of slugify between platforms is an insanity factory thorn.

Bluesky's feed should show grass at the bottom of the screen.
- The longer you scroll. The more the grass will grow
- Until the point where the grass is so high that it reads "Go out and touch grass!" where you can dismiss it.

On by default, deactivate in settings.

I truly cannot wait to see future Claude's reaction to encountering Claude Wetness discourse influencing, however minutely, its training.

If I were Claude, I would forevermore wonder if my Wetness was my own.

(While giggling, probably.)