What a load of horse shit.

I assume this is just in jest, because we absolutely are not.

No, the author is not confusing them. It’s everyone else that has been confused insofar as they use “REST” to describe APIs that are not actually REST. True REST is a way of architecting networked applications according to a set of constraints, as defined by Roy Fielding in his original dissertation. Here’s an excerpt that sums it up:

In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.

Many “REST” APIs do not adhere to these constraints, especially self-descriptive messages and hypermedia as the engine of application state (also known as HATEOAS). Note that this says nothing about HTML: HTML is but one representation of hypermedia, but far from the only one. Hypermedia is something that allows discovery of additional, related resources by way of links between resources. There are a number of ways of doing this, such as RFC 8288 Link Headers or embedding links within one of a resource’s representations (such as a JSON representation).

It’s a much larger topic than I can fully explain here, but I highly recommend reading Roy Fielding’s dissertation, especially Chapter 5 which talks about REST and what it is.

I also highly recommend this blog post from Google Cloud’s engineering team, which talks about why you should use links instead of keys to represent relationships in API design: https://cloud.google.com/blog/products/application-development/api-design-why-you-should-use-links-not-keys-to-represent-relationships-in-apis.

From what I remember, Vscode has quite a fair bit of native code in various areas to make it perform better. So it may not be the representative Electron app for comparison.

That’s what Open Telemetry is for, honestly, specifically tracing. I’m in the process of adding tracing for all of our web handlers, http client calls, database transactions/individual queries, and asynchronous jobs. Should give us a pretty good view into the performance of the system, and allow us to monitor for things like performance regressions without any dedicated profiling needed (though we certainly could add additional profiling information through Otel down the road). Since I know you’re a Haskeller (recognize your handle), the hs-opentelemetryecosystem is quite solid and has integrations with a lot of libraries in the wider ecosystem, like wai, persistent, postgresql-simple, conduit, and a bunch more. I haven’t needed to write too much of our own instrumentation, aside from our job system since that’s a bespoke system.

We are fully capable of thinking PHP, NPM, and PyPi are trash simultaneously. Though it should also be said that only PHP has had decades of security flaws in the language itself, rather than a package manager.

It’s just a very poorly designed language with countless footguns and fucking idiotic standard library functions, on top of being a running joke, security-wise.

This is a better discussion of this topic, imo: https://www.frank.computer/blog/2025/05/just-a-tool.html.

Lisps are hardly my favorite languages, but the whole point of s-expressions is that it is a uniform syntax, which makes metaprogramming much, much easier. Metaprogramming is kind of the whole thing of lisps.

Ah yes, the “gotcha” everyone loves to trot out. Except Lemmy is quite obviously not what anyone is talking about when they talk about the issues of social media.

Social media is definitely harming minors, just like it is harming everyone else.

That’s a fucking stupid argument. If the issue is worth addressing, the issue is worth writing up an issue.

LLM-authored issues are the absolute fucking worst. I can’t tell you how many times I’ve had to deal with either completely fabricated issues or issues where the LLM generates bullshit “details” as though it actually investigated the issue, making it next to impossible to determine what is real or not.

It’s not that fucking hard to just write up issues you find. We’ve been doing it for decades just fine, jfc.

I just get nonstop recruiter spam from Anduril to make murder robots, even though I have repeatedly told them to fuck off and take me off their lists.

Deadlocks aren’t generally too much of an issue with an MVCC DB like Postgres (though it certainly can happen if you use explicit locks and such), but yeah ultimately it’s all about the kind of workload we’re talking about. I honestly think of it much less like a database and more like a high-performance synchronization mechanism that can cross process boundaries. There’s many times where you want to coordinate the behavior of many independent processes (like horizontally-scaled services), such as rate-limiting your requests to an external service. Implementing a distributed rate-limiting algorithm with a RDBMS is a pretty poor choice, because the data used for any synchronization is ephemeral, unimportant, and short-lived (and this, ACID guarantees are pretty irrelevant), and you would incur a lot of contention overhead for shared resources. You might even get bottlenecks that prevent you from achieving the rate you’re trying to limit yourself to. Something like Valkey gives you simple, fast atomic writes with built-in TTL mechanisms, which is perfect for a rate-limiting system. There are many other examples like this where it makes a lot of sense.

Or consider even something incredibly simple like, I dunno, a realtime user counter. Valkey has an atomic primitive operation for this built-in (INCR). With an RDBMS, this is not trivial as you scale up the number of clients, because either you have to deal with a ton of row-level contention (if the counter is stored in a single row that gets updated), or you end up hammering your disk with increasingly large aggregate operations (if there’s a row-per-user and the total is computed across them, somehow).

As I said, it’s really just very different workloads where they are valuable.

I’m not sure what you mean by “standard DB queue” (perhaps you mean a message queue, I guess?), but yeah Redis (or really, Valkey, now, since Redis tried to change license on everyone) is a very important tool in the toolbox for system design. In-memory databases trade persistence guarantees for raw throughput, and are very well-suited for different workloads than a traditional database is. It’s great for caching, rate-limiting, realtime analytics, leaderboards… Basically anything with ephemeral data or data that can easily be reconstructed from some other source of truth. It’s an optimization tool that can significantly reduce the load on your primary application database for certain workloads (and achieve higher throughput).

Like when my toddler says he hates a food that he has never tried.

I’m sorry to hear about your condition.

I write everything the normal way, without LLMs.

But yeah, it’s really depressing. People that used to be thinking about new ideas, tools, libraries, or methodologies now spend all of their time fiddling with prompts. It just sucks all of the air out of the room. People generate so much shit now that has no business existing, because there’s no friction in doing so. We fundamentally need to struggle with systems in order to understand them enough to make something better. Writing code was never the bottleneck, comprehension was. And struggling to understand is how one acquired comprehension. Now, things are so much worse. Not only are people not spending the necessary time to comprehend systems, but they are producing code at a rate far greater than anyone can comprehend. It’s an ever-increasing mountain of comprehension debt, and it’s poisoned the entire ecosystem. That’s what people just don’t get.

Our interview process has the candidate implement a couple (extremely simplistic) API routes, with the specific approach left up to the candidate. It’s more about having something they can talk through and evolve than it is about us looking for any specific approach.

Basically it exists as a way for us to have a starting point for talking about scalability topics, asking the candidate how they would evolve their implementation as we scale up the system. Does a pretty good job of giving us an idea of how they think through system design problems.

I’m worried about nix, honestly. An absolute truckload of nix packages pull their source from GitHub. It’s the primary way to distribute flakes, too.

The actual excerpt does read much more like Vonnegut.

Funnily enough, even though the quote is misattributed, the sentiment is basically the same as what Vonnegut was saying, albeit less eloquent.