Very weird style. Inconsistent heading styles. Four tilde code blocks? That’s totally nonstandard. Why?

Yeah unfortunately these numbers don’t really allow any conclusions to be drawn at all.

Also they’re not really related to supply chain security which is more about deliberate subterfuge. I think the interesting stat there would be how many authors are being trusted typically for each crate.

because someone believed an ANSWER on a different question answered my question

Yeah that is actually their official position. Your question is duplicate if an answer elsewhere might answer it, which is clearly absurd. Essentially they think “what’s 1+3?” is a duplicate of “what’s 2+2?”.

I think fundamentally they gamified moderation too well, and for many people they turned the site into a mod-maxing game, which obviously makes it an abysmal place to be for normal users.

It isn’t really. This is based on slightly implausible statistics and an unusual definition of “growing”.

No, generally people are annoyed that you’re spending time paying off tech debt instead of piling on more.

having the data inline

It’s not as simple as that, depending on the architecture. Typically they would fetch 64-byte cache lines so your 128 bytes aren’t going to be magically more cached than 128 bytes on the heap.

Avoiding allocations may help but also maybe not. This is definitely in “I don’t believe it until I see benchmarks” realm. I would be really really surprised if the allocation cost was remotely bad enough to justify the “sorry your file is too long” errors.

Can’t remember tbh. It was a work setup. It wasn’t an unreasonable one though. 32 is not very many!

I hit a bug recently in KDE Wayland where the task bar was just slightly offset from the edge of the screen, so there was a gap behind it. Very dumb.

OPAM (OCaml’s package manager) had a bug where it couldn’t find curl or wget to download stuff with (don’t ask me why it shelled out to those in the first place) if you were in more than 32 Unix groups. Have fun thinking of a reasonable explanation for that!

Even if there are tight time constraints, you won’t sacrifice quality, because that would make you slower.

Too right. People find this so hard to understand. I think they dramatically underestimate the payback time on technical debt.

I am currently working in a startup that has the classic “we’re a startup, quality doesn’t matter” attitude. They think that they might not be around in a year so it’s best to go fast and not give a shit about tech debt.

In my experience that attitude bites in under 6 months. I’m already wasting entire days sorting out messes that they neglected to deal with.

22 characters is significantly less useful than 255 characters.

You can still use more than 22 characters; it just switches to the heap.

nothing I am going to store is ever going to require heap allocations

I would put good money that using 256 bytes everywhere is going to be slower overall than just using the heap when you need more than 22 characters. 22 is quite a lot, especially for keys. ThisReallyLongKey is still only 17.

It’s just not a very good name. Awkward even without the mpreg/preg thing. Steps on ffmpeg’s toes too much. Just pick something unique. Videoh. Muxy. Movrify. Flippityflop, whatever. I thought about those names for literally 10 seconds. You can definitely do better than ffmpreg if you think harder!

I mean, it would be great if this succeeded… ffmpeg is nice and all but its interface is clearly terrible and there’s absolutely no way it is remotely secure. Anyone that uses it on a server basically has to run it in its own VM, or a severely locked down sandbox.

But good luck supporting all the codecs people expect. I’m not even talking the obscure ones ffmpeg supports; just the ones “normal” people use will be a life’s work.

Also you have to change the name!

Quite well known now because Rust-haters like to point out how they’re awkward to use in Rust.

Interesting idea, but your trick is never really going to help (you can store up to 255 bytes instead of 254). Also always using 256 bytes for every string seems wasteful.

I think LLVM’s small string optimisation is always going to be a better option: https://joellaity.com/2020/01/31/string.html

Obscure 10 years ago maybe. These days there have been so many articles about them I bet they’re more widely known than more useful and standard things like prefix trees (aka tries).

Everyone is talking past each other because there are so many different ways of using AI and so many things you can use it for. It works ok for some, it fails miserably for others.

Lots of people only see one half of that and conclude “it’s shit” or “it’s amazing” based on an incomplete picture.

The devs you respect probably aren’t working on crud apps and landing pages and little hacky Python scripts. They’re probably writing compilers and game engines or whatever. So of course it isn’t as useful for them.

That doesn’t mean it doesn’t work for people mocking up a website or whatever.

I think this could have been about 1/4 the length. Fairly basic stuff by modern standards and you don’t need so many words. It is all correct at least, as far as I could see!

I mean yeah I guess that’s its primary purpose if you totally ignore the fundamental thing it’s meant to be doing.

It’s like saying the primary purpose of a seatbelt is to be easy to fasten and unfasten.

Of course I wouldn’t write in raw machine code, or even assembly. We invented higher level languages that are more powerful and easier for humans to use…

But the purpose is still to make machines so stuff!!! I’m not just writing code so that other humans can marvel at my algorithms.

This is so freaking dumb.