YSK that a lot of common questions/complaints about Lemmy are presently answered by kbin
ADHDefy@kbin.social to 
This is not an attempt to convert Lemmy users, nor is it a slight on Lemmy. I'm sure there are plenty of reasons why Lemmy works better for some, and I love the fact that we not only have multiple choices, but multiple choices that allow us to interact with each other regardless! It's amazing. Lemmy is great, no shade.
With that said...
Why YSK: I see a lot of users posting frequent questions about Lemmy that are currently answered by kbin.
For example:
- The ability to block a whole domain, or subscribe to one
- The ability to subscribe to individual users
- A built-in search tool to find communities all over fedi (kbin, Lemmy, Mastodon groups, etc.) with an indication of how active they are
- Mitigation for the "tracking pixel" issue
I find that almost every day, I see Lemmy users asking about features and I think, "well, kbin does that." I think it would be worthwhile for more users to check into both platforms and decide which might be best for them.
You are viewing a single comment
What I've been curious about is the relative performance of kbin (PHP) vs. lemmy (Rust) server code. Rust is supposed to be many times more efficient performance-wise than PHP as far as I know, but has anyone compared this in practice? The presumed ease and speed of adding features to kbin because of PHP may come at a high performance cost (read: carbon emissions too). Does anyone have any further insight into this?
Probably something you'd notice more in the number of concurrent users each solution could handle per web server instance. Rust theoretically would let you serve more users with less resources.
Disclosure: I dislike PHP.
Right, essentially this is what I was thinking - more vs. less users per CPU core.
PHP is fine as long as you don't try to do too much with it. For simple GET/POST requests I wouldn't be surprised if there's not much difference performance wise. If you start trying to do any complex processing or data aggregation in PHP (which should probably be done on the database side with queries anyway) then the performance will really fall off a cliff. Especially because PHP is (for web) single threaded. Threading is possible but it'll cause far more headaches than it's worth. Best to keep it simple and use a more appropriate tool if more complex processing is needed.
Thanks for the insights!