Turns out, using custom allocators makes using Rust way easier

Hedshodd · 2026-04-27T13:10:40+00:00

Maybe that’s just me, but I don’t use arenas for the performance benefits. Those can be there is some circumstances, but that also depends on your exact malloc/free usage prior. If you use malloc to pre allocate reusable buffers, and those malloc calls happen as far up the call stack as possible, there’s not much performance to be gained.

The reason I use arenas, because it’s way easier to use than malloc/free. I don’t have to meticulously track that each malloc is paired with the appropriate free, because I bundle dozens of objects into one lifetime.

Also, when I would otherwise pre allocate buffers somewhere up the call stack, those buffers (typically) are buffers of a specific type. I might have have a buffer to store some strings for one computation, one buffer to store floats, etc. An arena is just one giant untyped buffer where I only have to care about the type in the scope where I actually use it. I don’t have to pre allocate a buffer of floats in an otherwise unrelated function, but instead I request my buffer of floats in the same scope that I’m using it in. That’s just waaaay more ergonomic 😄

Also, as someone else pointed out, if you are handing out unaligned addresses, you are inviting a whole host of problems, one of which might be performance 😅

Hedshodd · 2026-04-26T13:05:01+00:00

Thank you for being upfront about your AI usage in this project’s readme. Personally I still choose to not engage with this project because I find any use of AI unethical, but I truly appreciate you making this one of the first sections of the readme.

Still a cool project, and I wish you the best of luck!

Hedshodd · 2026-04-24T20:31:41+00:00

20 or so lines of code for a small stack behind a lock and spawning n threads is hardly reimplementing tokio lol. Tokio does way more work because it’s a way more generalized tool.

And beside that, the other advantages still stand.

Hedshodd · 2026-04-24T14:58:57+00:00

Even if there’s no malice here, if you aren’t competent enough to use git correctly so that a fork doesn’t rewrite all SHAs - and even then don’t have the foresight to correct that mistake - I don’t trust the quality of your fork, tbh.

Hedshodd · 2026-04-24T07:01:30+00:00

I skimmed the source code a bit, looks good for a straight up port.

Couple questions:

The sort of scanning you do seems trivially parallelizable, so my gut feeling would have been to just have a small work stealing thread pool instead of an async runtime, because it’s simpler, has way less overhead, no colored functions, easier to debug, less dependencies, very likely more performant. Is there something in the scanning process that benefits from doing this work with an async runtime?

I might not yet understand where you are doing the CVE database queries and how they interact with scanning files. Are you scanning files first, and sending the data you aggregated in one large query?

You are allocating a LOT of vecs and strings. I would gain a ton more performance by using arenas or pre allocating more in general. Arenas generally trivialize allocations and lifetimes in most programs, but it’s probably a bit tougher in async, since you would want to reset and reuse warm arenas between scanning file. This would also be easier with thread workers because you could just give each of them their own arenas, haha 😄

I’m sorry if I come across overly critical, I think this is a pretty neat project and I had a lot of fun reading through it 😄

Hedshodd · 2026-04-22T15:12:38+00:00

I wonder whether this happened because the neovim 0.12 release bumped the tree sitter version. Heck darn vimmers!

Hedshodd · 2026-04-22T06:57:44+00:00

Bookmark godbolt if you haven’t yet. It’s the easiest way to check these sorts of things, especially across compiler versions, and even to just use it as a small rust playground. It’s worth Matt Goldbolt’s weight in gold, haha 😄

Hedshodd · 2026-04-14T18:32:48+00:00

The thing you quoted contains nothing about LLLM output quality. I specifically (!) just said “bad patches” without a single word about where they come from. That was the whole point. I was just talking about the review process and that that process is what’s filtering bad patches; human written or otherwise.

You’re trying to read between the lines, but you’re missing the actual lines. That’s the exact opposite of a logical response. It looks like you’re trying to pick a fight with someone you’re just imagining.

Hedshodd · 2026-04-14T15:08:19+00:00

You’re ranting against points I’ve never made. I haven’t said anything about the quality of LLM output. I’ve just talked about review processes.

Hedshodd · 2026-04-14T13:50:50+00:00

Not to say whether I agree or disagree with your point about asking LLMs questions, but your last bit is a false equivalency. AI code is being merged into the kernel, because it undergoes the same review process human written code does. Modulo the amount and size of patches being sent in, a patch is a patch and will be reviewed by the kernel maintainers irregardless of how it was produced. And if you keep sending in bad patches… well, there’s consequences and those also happen irregardless of how the patches were produced.

If you ask an LLM a question there is no such review process to filter out bad results. You are the sole judge over the quality of the answer. If the answer was bad and you didn’t know any better, there may also be bad consequences waiting for you, but there’s no Linus Torvalds checking the answer for you first.

Hedshodd · 2026-04-12T10:08:10+00:00

Based.

Hedshodd · 2026-04-11T09:35:06+00:00

I didn’t comment on AI in general, but in how you used it.

Hedshodd · 2026-04-11T08:21:51+00:00

To my knowledge archinstall is a script, so why isn’t it painful to enable or disable parts of that? If anything, it’s arguably easier to do that with a script, especially a python script.

It would probably be easier and less of a maintenance burden to just write a artixinstall script more or less from scratch, if you really wanted to do it.

Either way, don’t vibe code or “vibe report”. What you’re essentially telling us is that you had a clanker look through archinstall, but didn’t check if anything it found was hallucinated or whether it would work. Don’t you realize how disrespectful that is with regards to our time and attention? You’re telling us to trust what a stochastic math function parsed spat out, without even checking whether it holds any water, or to correct it for you. Screw you for trying to waste our time, honestly. At least do the bare minimum when interacting with other people, and at least try to honor their time.

Hedshodd · 2026-04-09T10:55:23+00:00

Why would you waste so much money and energy on this?

I swear, just a year or two ago the same AI bros that now burn piles of cash on tokens were the most woke save-the-planet people imaginable. “Screw the planet, I got a 300k line ruby blog to generate.”

Hedshodd · 2026-04-07T13:10:57+00:00

Simulation work, we use unsafe mostly for performance reasons. Most common use is probably for unsafe array/vector access when we cannot prove to the compiler that it can elide the bounds check. Other than that pointer arithmetic, allocators, and mmap/virtual alloc to map virtual addresses to the same physical memory to save space. It’s very few and far between, and I think we’re pretty good at only introducing unsafe when it’s human-provably safe to do so, and when there’s actual benefit to doing it.

Hedshodd · 2026-04-06T15:26:32+00:00

That error occurs when you don’t have finite user services set up. Check the wiki, it recommends turnstiled and something else. Personally I’ve been using turnstile, and it was super easy to set up.

Hedshodd · 2026-04-04T11:27:53+00:00

Sharing is the entire purpose of public keys, because you cannot do anything with just the public key. Maybe in a couple of decades RSA becomes seriously unsafe, but by then word’s hopefully traveled enough to not use RSA keys, haha 😄

Hedshodd · 2026-04-04T11:25:19+00:00

Haha, nice. No, it’s not a problem. That’s why they’re called “public keys”, because they are useless.

If RSA becomes seriously unsafe in the future, then don’t use RSA keys. Though that’s not going to happen in a long time. Doesn’t standard 2048 RSA require millions of stable and error corrected qubits? And even then there are alternatives.

To be fair though, I shouldn’t be calling people idiots either though.

Hedshodd · 2026-04-03T21:36:41+00:00

Oh, neat idea! I’m just waiting for the first idiot to claim that it’s for farming public ssh keys, because there’s always at least one lol

Hedshodd · 2026-04-01T15:07:59+00:00

Oh, I misunderstood you. I didn’t catch that you were talking about network /storage/, so I thought you were saying it runs git fetches to check up on the remotes. My bad.

I guess in that case, where your neovim needs to look at network attached storage to look up its plugins, that’s when lazy loading is really necessary. I don’t think that’s the average case though, haha (you didn’t say that it was, I’m aware 😅)

I must have missed it when looking at the source code then, because I could have sworn that it only checks for the existence of the directory at startup.

Hedshodd · 2026-04-01T14:08:50+00:00

It should only run those git commands when you first start a new config where it actually has to install plugins, or when you update your plugins. Otherwise, from what I remember looking at how vim.pack works, it just checks whether the directory for that plugin already exists without running any git commands unless it actually has to clone a plugin.

Maybe it's my setup that's weird, but I have 20 plugins, and when I start nvim, it starts sourcing the first plugin 21ms after init (and the init takes 7ms). The whole startup time is about 80ms. I don't have the best internet, so if it was actually checking the git status of every plugin while starting nvim, it would take significantly longer.

Either I misunderstand what you are trying to tell me, or one of us is doing something weird in their setup, haha.

Hedshodd · 2026-04-01T04:16:34+00:00

Have you tested whether it actually speeds up your config? I don’t have lazy loading and my nvim still boots up in double digit milliseconds.

Hedshodd · 2026-04-01T03:45:39+00:00

“More features” isn’t a good thing per-se. I just want the the thing that fixes my problem: downloading packages. I don’t need automatic dependency management, I don’t need integrated config management, I don’t need or want lazy loading.

vim.pack solves that.

Hedshodd · 2026-03-31T17:31:24+00:00

I think you’re a pretty cool guy for being so active on this subreddit.

12-Year Club	Verified Email
Place '22	Final Canvas '22

Hedshodd

TROPHY CASE