skavi

aren’t there also nix lsps

4k stretched to 32 is awful. screen door very visible. honestly it’s not even quite enough for 27.

nothing like some killing to get you settled down.

Forces better code structure in my experience (ignoring orphan rule). modules can have dependency cycles and things get tangled together. crates disallow cycles.

would you be willing to be more specific on what insights i've missed?

regarding the GP's comments on article content, i suppose maybe one critique could have been sharpened by a closer reading?

> There could be some value buried in there

i'd imagine you agree.

> could have been 10% of its size

likely false, but i interpreted this as an intentional exaggeration

> could have been human written

likely true

a lot of human effort clearly went into this work. so the term "slop" is harsh. but its also a bad look to lash out at that label and claim that people Just Don't Get It. check out https://bcantrill.dtrace.org/2025/12/05/your-intellectual-fl...

i think that is a bad tradeoff. interested non-experts can use their research tool of choice. but more likely they are not going to get past the first few paragrahs. is there some reason that all posts on a blog must be understood by all readers of said blog? perhaps a tag could identify technical posts.

also, i'd expect the LLMness of that intro to bounce at least as many people as the additional context you've included retains (~0).

> We had LLMs write precise mathematical rules, or a formal semantics, for how a small programming language should behave. We then used Lean, a tool for checking mathematical proofs, to prove that the interpreter—the program that runs code written in that language—follows those rules even after being compiled into low-level instructions understood by a RISC-V computer chip.

who is your audience? why are you defining every single term here? perhaps i am less tenacious than most, but i wouldn't expect many who are unfamiliar with interpreters, formal proofs, or assembly language to be willing to charge on ahead—even when armed with that additional context.

also, writing your very first paragraph via LLM is certainly a choice.

what's with this driver being coupled to an IDE? is one the psychosis enabled bikeshed of the other?

but you have invented syntax

because i was stupid lol. i’d only done (very) basic duck typed generics in c++ before then.

all i wanted was to add a new method i could call in the same way as all the methods on Iterator (map, filter, etc.). and was suddenly confronted with `impl Trait2 for T where T: Trait1`. which makes perfect sense now. but at the time was unparseable.

for my own sake, i’ll note that i started learning rust in 2020. i’m no longer confused about Traits.

unfortunately, It Depends.

different people struggle with different things. your existing experience is a major factor. there are a lot of concepts in rust that you may have already figured out in another language.

personally, i started learning rust two years after i started programming. at that point i had basic experience with c, c++, and some assembly.

i struggled with pretty much everything. i recall traits being particularly confusing. i’m not sure i fully got them until i messed with typeclasses in haskell at some later point.

but, honestly, i don’t remember struggling too much with lifetimes. i think the compiler is pretty good at suggesting fixes for common issues. i think it was helpful that i knew what a pointer was and had debugged segfaults. also, i didn’t really have an existing way of structuring programs that i was trying to reconcile with rust.

Box, Arc, and Rc you’ll figure out as you need them. you can think of them as tools which let you escape lifetimes.

Pin you won’t need to think about for a very long time [0]. You should check out my guide [1] if you’re interested though :). There are many others.

[0]: unless you’re the guy i’ve tasked with fully understanding FuturesUnordered as his very first introduction to Rust, lmao.

[1]: https://github.com/soooch/async-intuition/blob/main/src/pin_...

probably not to your current computer. this works on supporting memory types that do compression in hardware.

vox looks great! actually kind of reminds me of the look that elementaryOS goes for with the subtle drop shadows and the softer coloring. or maybe older macOS.

at the same time, vox doesn't really look like a lot of other QT apps (whereas a lot of modern GTK apps tend to have very similar designs).

notes seems like a great app. ux seems great from the demo reels. but it doesn't look quite as nice to me. the drop shadows (on click and drag) seem off. many things are very flat and wireframe looking. the icons look "cheap" (trashcan and slider/config particularly). i am unsure on how you choose between full black and dark grey in your design system but it feels a bit inconsistent.

all that said, i think the animations look great. very smooth.

I will continue using GTK until QT decides to stop being ugly (by default).

If you want an AoT compiled almost-Python, why not use Mojo?

i think you mean a word that’s not craven

Do you know what wasn’t successful?

Fuchsia is the only OS that uses that kernel.

Also, that was an easily citable doc line, but I think a more comprehensive look at the work done in Fuchsia shows it has or had ambitions to run on personal computers.

e.g.: fancy graphics stack, Linux compatibility layer, ideas about OS integrated cloud syncing, the original work on the Xi text editor.

I’m more interested in whether it’s still a thing people want to work on rather than something people are forced to maintain.

It wasn’t actually. From the docs for Zircon (Fuchsia’s kernel) [0]:

> Zircon targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation.

Fuchsia also had a Linux compatibility layer similar to WSL1 at some point. Might still be there?

[0]: https://fuchsia.dev/fuchsia-src/concepts/kernel/zx_and_lk

Interesting to see a mention of Fuchsia on a big Google announcement. Is the project still truly alive? Are the ambitions still as grand? Is the team as stacked as it used to be?

Also, a link to the rust root of Zircon in case anyone else was interested: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/z...

if you mean that all war is unjustified, consider stating that plainly. if that's not what you mean, then perhaps there is some nuance left out of your statement.

Would anyone be able to compare this library's design to https://github.com/google/highway?

direct link: https://www.servethehome.com/micron-evolving-memory-architec...

> Are you sure you don't just have an axe to grind? Because that is an exceedingly uncommon edge case. Typically you only have a few threads and you aren't inundating the allocator with requests thus it is unlikely to make any practical difference.

Totally fair, and I agree that you should only have a few threads (or TPC) and shouldn’t be inundating the allocator with requests. But I’m only grinding this axe because I’ve personally had to deal with a system that went against most of that guidance.

We ran far too many threads in a memory-constrained environment. Thread count was many multiples of core count.

I totally agree that this is “questionable territory”, but honestly, any application that’s outgrown the basic glibc malloc has made a few mistakes.

very naive question: does organ even have a strict enough definition for discussions like this to be worthwhile?

> seems likely to be a wash at absolute best

maybe i give it too much weight, but:

> massive oversubscription of physical CPU cores (ie tens of thousands of threads) where TLS becomes utterly wasteful while also thrashing the cache

seems worth solving to me

yeah that’s a common mistake when evaluating tcmalloc. gperftools tcmalloc diverged quite a while ago. doesn’t have a lot of the fancier features of modern tcmalloc [0].

[0]: https://github.com/google/tcmalloc/blob/master/docs/gperftoo...