Yup, I also do that. If I just need a variable to put in what will be returned, I call it result. What it means should be clear from the function name. Repeating that feels redundant.

Pff. I know someone who generated programs using XSLT.

A serif font on a computer display?! Appalling! Sacrilegious!

Flutter is quite nice too. Closer to web dev, but still pretty close to native.

Thank you for your thorough explanations and input. It definitely gave me a few things to think about. And if I have some spare time I might even try to spin up lemmy in some local k8s to see how it reacts to being scaled up and down.

Well, one could try to swap postgres for cockroachdb. But a ticket in github that asked for clustering support was closed with being out of scope. So might be lemmy is not stateless. Haven’t checked the code yet, though.

Doesn’t solve the availability issues, though. I know of no seriously hosted system that doesn’t have at least two replicas in different availability zones. I don’t expect any hobby instance to offer any kind of availability guarantee. But if we want to have one or two central instances that the typical reddit user can flock to, this would IMO be essential to have.

Also, in my experience it is FAR cheaper to have a few low to mid range systems for vertical scaling, than to throw a high end machine at it for vertical scaling. If you look the the pricing, the monthly costs for vertical scaling goes up exponentially once you want much more RAM and CPU cores (and storage, and so on).

Being able to scale horizontally solves both issues: hardware is cheaper and reliability is higher.

That lemmy is so damn efficient would then simply mean, that we can achieve excessively good results with low resources, where Reddit would already struggly and needs to put much more machines in place. That would be a nice “business” advantage.

What? How is it solved exactly? If say lemmy.ml is down, what’s the point of other servers existing, […]

Because you want to rely on someone else’s instance. The idiomatic solution would be for a community to host their own lemmy/activitypub instance and join the federation. Then the community has control over their own data. In every sense. If they want to delete something (for breaching law, protocol, or whatever), they are free to do so and don’t have to ask anyone else.

IMO the way the way the federation should’ve been designed is to use something like blockchain technology […]

Please no. I mean there is IPFS out there that somewhat works like that, but I don’t really like that. First, the ever-growing amount of data means that every instance has to keep up with it. If they wouldn’t replicate it, the deletion of a single instance would still eliminate the data, even if there were references in a block-chain.

Also: the ability to “forget” is important. Not everything needs to live on forever. That it currently does, can already be a big problem. Look how peoples lives got almost ruined because someone dug up tweets from 10 years ago that were stupid. Solving the issue of data ownership is IMO one of the bigger things we need to keep in mind when designing a better web. Federation with the ability to “just” bring your own instance along where you are the owner is one of these options.

That however would be a different problem. A horizontally scaled instance would be able to cope with more users, but if it shuts down for monetary, personal, or whatever reason, it’s still down.

Protecting a community from this is what the decentralized part is for. That is already in place.

(Although there is a middle ground where you could design the system in a way that one instance is mirrored and load-balanced across different hosters. That would actually also be quite interesting to have. But that’s another layer of complexity on top.)

I think lemmy will be bitten in the ass by not having considered clustering/horizontal scaling from the start. Federation alone as a scaling mechanism is only feasible for “nerds”. But if the network wants to grow, we will need a few scale-able large hosted instances. And if their only choice is to scale vertically, there will be a hard limit (unless we put a good old Mainframe somewhere ^^).

Another downside of this design is: you can’t run it with high availability. If there’s only one process per instance, updating it will mean the whole instance is down. Sure, if all goes well this downtime is under a second. But if it doesn’t go well or if a migration is needed, this might quickly become hours.