hazel★ @fractal.beauty · 19/09/2026wishlist: rustfmt-compatible tokio::select! (i think this exists but i haven't looked into it) 111
hazel★ @fractal.beauty · 29/08/2026i prefer to name things using pairs of words that have the same length: source/target, inner/outer, incoming/outgoing. as opposed to left/right, start/end 050
hazel★ @fractal.beauty · 29/08/2026tbh i remember watching the talks and reading the blog posts but i do not remember what the use<> syntax actually does at all 040
hazel★ @fractal.beauty · 27/08/2026can we have models that are RL'ed with concurrent human edits. please stop reverting my changes and blaming some autofix it's very annoying 050
hazel★ @fractal.beauty · 26/08/2026has anyone else noticed that an increasing share of reddit commentors are actually LLMs 150
hazel★ @fractal.beauty · 22/08/2026would like -ui to commit; i often describe but forget to create a new change after -ui to split/squash/absorb/etc selected lines within files haven't tried it in a collaborative repo yet 010
hazel★ @fractal.beauty · 17/08/2026i spawn a thread for a tokio runtime and give the host language a handle using uniffi. it can call sync functions or poll async functions using its async runtime, but tokio isn't available usually i've used channels to pass msgs, but to spawn a task directly, stashing the tokio handle worked nicely 030
hazel★ @fractal.beauty · 11/08/2026the problem is that it doesn't look good without overlay scrollbars because you have to see the scrollbar track all the time. so for example if you have a footer with a background color, the background stops at the gutter and looks weird. i don't think there's a good way around this 020
hazel★ @fractal.beauty · 09/08/2026in long(er) form: fractal.beauty/two-weeks-wi...fractal.beautyTwo weeks with Jujutsu 020
hazel★ @fractal.beauty · 09/08/2026i think the conceptual model is simpler, the commands are more obvious, there is less weird stuff to run into. otoh gui tools/ecosystem/etc are less mature. if someone is already comfortable with git i don't think they necessarily need jj. but #1/2 at least have made my life easier already </reply> 110
hazel★ @fractal.beauty · 09/08/2026i think if i was recommending a vcs to someone who had never used git before, and they won't ever need to interact with others (although it's possible, but they'd still probably need to learn git at some point), i could comfortably recommend jj 100
hazel★ @fractal.beauty · 09/08/2026-easier to keep a clean history using split/arrange/squash (all doable in git but less intuitive) -easier to rebase (especially stacked MRs) -easier to resolve conflicts (in theory; i haven't had any large conflicts to resolve yet in practice) -fully interoperable with git for everything i've needed 100
hazel★ @fractal.beauty · 09/08/2026tbh, i am trying it because it's trendy, but ime so far: -easier to undo mistakes (and by extension run commands more confidently) -easier to switch between wip work (no stashing; you could make wip commits in git but it's more to manage. also easier to split out new branches/MRs) 100
hazel★ @fractal.beauty · 09/08/2026i love programming, i love writing rust, i could write code forever 0100
hazel★ @fractal.beauty · 05/08/2026given time/motivation, i would like to improve the state of these, or at least upstream more of our patches at dayjob 010
hazel★ @fractal.beauty · 05/08/2026it is fairly reliable at least? there are sooo many bugs in the react native ecosystem libraries. when i was starting out these would have been very difficult or tedious to debug. LLMs have also made it a bit easier 110
hazel★ @fractal.beauty · 05/08/2026we (i) have poor debugging tools (for react native). the most reliable (and tedious) method (that i know of) to find bugs is to recompile native code in dependencies etc with a bunch of logging. that can't be right 150
hazel★ @fractal.beauty · 29/07/2026it was connecting to 6ghz instead of 2.4 and it couldn't switch because the 2.4 network needed wpa2 but it was configured with wpa3, maybe 020
