iiinova — where your digital self keeps evolving

Reposted by Alice ✨

Blog post about instrumenting Lix evaluation with Tracy informal.codes/posts/tracy-lix

right?? the only reason I ever use it is to get to the download button (that is of course unclickable until the reader has finished loading lol)

010

Alice ✨ @welltypedwit.ch · 19h

my favorite is how if it breaks (which it does pretty regularly because of course it does), the button it shows you on the error message to navigate away is also unclickable

010

Alice ✨ @welltypedwit.ch · 19h

it's genuinely impressive how often the acm pdf reader thing makes every button unclickable i would not know how to do that intentionally without putting in a lot of extra effort

4111

Alice ✨ @welltypedwit.ch · 30/09/2026

yes. it's also older than rust ^^ e.g. i found a random haskell cafe thread from 2008 that mentions it: mailman.haskell.org/archives/lis...

mailman.haskell.org

Re: [Haskell-cafe] Fighting the monad stack, MonadIO - Haskell-Cafe - Haskell.org

180

Alice ✨ @welltypedwit.ch · 30/09/2026

(that one does come up occasionally though since `case x of Blah y -> y` has different semantics depending on whether that Blah is a newtype pattern or a regular data constructor pattern)

030

Alice ✨ @welltypedwit.ch · 30/09/2026

it's very common in haskell as well. i don't think i've heard "newtype pattern" before, aside from like, a pattern that matches on a newtype

2100

Alice ✨ @welltypedwit.ch · 29/09/2026

idk, maybe it's not that bad though. one nice advantage i have is that boxing twice doesn't actually do anything so you at least couldn't accidentally pessimize your code that already explicitly boxed things

020

Alice ✨ @welltypedwit.ch · 29/09/2026

yeah but if you decide that this thing should be boxed at that stage, then that might have a pretty serious performance cost since it now suddenly needs to insert box/unbox operations everywhere and that cost is very hard to see from the user's perspective

220

Alice ✨ @welltypedwit.ch · 29/09/2026

well it is strictly faster than even your working solution here so... ^^ (it's also definitely a moving gc. currently it's entirely generational copying but i would maybe like a concurrent non-moving major heap later, depending on how much i want future alice to hate me when she has to debug it)

120

Alice ✨ @welltypedwit.ch · 29/09/2026

(if i do it entirely as an optimization in the backend, you will get very subtle heap allocations and if i do it on the frontend where it impacts types, i need to decide what "too large" means and that gets very messy once you involve abstract types that don't expose how large they actually are)

120

Alice ✨ @welltypedwit.ch · 29/09/2026

(i'd like to auto-box large representations automatically at some point, i'm just not really sure how to do it in a way that is transparent)

120

Alice ✨ @welltypedwit.ch · 29/09/2026

and you wouldn't need any downcasting tricks since the string stored inside the JSON is also just its own heap object that you can share however you want without copying anything

211

Alice ✨ @welltypedwit.ch · 29/09/2026

if we assume that the `JSON` enum itself is large, you can just put it behind a Box and get something similar to your Arc solution, except a lot more efficient (no actual RC, bump pointer allocation)

110

Alice ✨ @welltypedwit.ch · 29/09/2026

✨garbage collection✨ ^^ so, your first approach would already Just Work because copying the json object would only do a shallow copy of a few bytes (since all the large values (strings, maps, arrays) are already behind a pointer and vega doesn't have ownership)

130

Alice ✨ @welltypedwit.ch · 29/09/2026

very cool!! (also obligatory "vega fixes this" ^^)

140

Reposted by Alice ✨

PolyWolf @wolf.girl.technology · 29/09/2026

New blog post: "Pining for Arc Downcasting in Rust" wolfgirl.dev/blog/2026-09-29-pining… #programming #rust

6243

Alice ✨ @welltypedwit.ch · 27/09/2026

but it also makes my goal of beating rustc in at least one benchmark seem much easier to achieve than i thought ^^

0110

Alice ✨ @welltypedwit.ch · 27/09/2026

i was really concerned for a second why my (naive, non-gc) vega code was so much slower but no, rust is exactly as slow lol (which makes sense since it's really just LLVM at that point and the entire benchmark is dominated by allocation performance anyway (which is why ghc is so fast))

1100

Alice ✨ @welltypedwit.ch · 27/09/2026

funny how if you pick the right benchmark, ghc can beat rustc by a factor of 10