Don’t quote me on this, but I’ve read lemmy is a few years old already while kbin is just a few months old (3-4 mos?). Add the number of instances (i only know of 3 kbin instances) and you can see why it didn’t take off the way lemmy did.
I agree. Purely text-based sites need a certain kind of audience/users. I love a good discussion/debate, but I need my memes, too. Lol.
The Kbin creator had initially joined to help Lemmy, but decided to create his own thing when he couldn’t take their political alignments anymore. The Lemmy devs used to be vocal Uyghur genocide deniers and pro-North-Korea, and would answer questions on Reddit’s r/AskATankie (a tankie is someone who supports communist dictatorships), but now that Lemmy is successful, they’ve kind of grown hush-hush on it, without really addressing it.
So, he went to create Kbin, but since he’s not a software engineer, he chose foundations that won’t really scale too well. Kbin is written in PHP, which is an interpreted and mono-threaded technology, it’s great at some stuff, but not high-scale services (source: that’s what I do for a living). Lemmy was written in Rust, which is compiled and multi-threaded. It doesn’t mean Lemmy won’t meet tricky scale bottlenecks, but it will give it a much larger toolset to get through whole classes of them.
And of course, Kbin being much younger, it doesn’t currently have a bunch of critical stuff that Lemmy already has. For instance: an API, which has been allowing other people to build great native clients for it.
Without an API, all clients would need to rely on scraping, which is slower and more resource intense - almost orders of magnitude. Until Kbin develops an API, it will always be less used.
This is interesting. Thank you for the info. Quick question, though: does this mean kbin will inevitably face scaling issues when it gets too big? And there’s no way to prevent that?
My best answer is: if they get to sufficient scale, both Lemmy and Kbin will face scaling issues to get through, but Lemmy is based on something that will make it much easier for humans to get through a lot of those bottlenecks.
I hope what this answer conveys is that the technology choice is a major factor, but not the only factor. If the Lemmy dev team doesn’t know how to scale a service, and don’t enlist the help of people who do, the underlying technology won’t make much of a difference. But it does give them a very strong upside.
Another Lemmy user was saying that the Kbin move to use PHP was like someone saying: “oh, I like the airplane you just built by yourself with the intention to fly above the clouds, I’m going to do the same thing, let me prepare my cardboard”, and there’s a lot of truth to it. 😉
Don’t quote me on this, but I’ve read lemmy is a few years old already while kbin is just a few months old (3-4 mos?). Add the number of instances (i only know of 3 kbin instances) and you can see why it didn’t take off the way lemmy did.
I agree. Purely text-based sites need a certain kind of audience/users. I love a good discussion/debate, but I need my memes, too. Lol.
The Kbin creator had initially joined to help Lemmy, but decided to create his own thing when he couldn’t take their political alignments anymore. The Lemmy devs used to be vocal Uyghur genocide deniers and pro-North-Korea, and would answer questions on Reddit’s r/AskATankie (a tankie is someone who supports communist dictatorships), but now that Lemmy is successful, they’ve kind of grown hush-hush on it, without really addressing it.
So, he went to create Kbin, but since he’s not a software engineer, he chose foundations that won’t really scale too well. Kbin is written in PHP, which is an interpreted and mono-threaded technology, it’s great at some stuff, but not high-scale services (source: that’s what I do for a living). Lemmy was written in Rust, which is compiled and multi-threaded. It doesn’t mean Lemmy won’t meet tricky scale bottlenecks, but it will give it a much larger toolset to get through whole classes of them.
And of course, Kbin being much younger, it doesn’t currently have a bunch of critical stuff that Lemmy already has. For instance: an API, which has been allowing other people to build great native clients for it.
Without an API, all clients would need to rely on scraping, which is slower and more resource intense - almost orders of magnitude. Until Kbin develops an API, it will always be less used.
This is interesting. Thank you for the info. Quick question, though: does this mean kbin will inevitably face scaling issues when it gets too big? And there’s no way to prevent that?
My best answer is: if they get to sufficient scale, both Lemmy and Kbin will face scaling issues to get through, but Lemmy is based on something that will make it much easier for humans to get through a lot of those bottlenecks.
I hope what this answer conveys is that the technology choice is a major factor, but not the only factor. If the Lemmy dev team doesn’t know how to scale a service, and don’t enlist the help of people who do, the underlying technology won’t make much of a difference. But it does give them a very strong upside.
Another Lemmy user was saying that the Kbin move to use PHP was like someone saying: “oh, I like the airplane you just built by yourself with the intention to fly above the clouds, I’m going to do the same thing, let me prepare my cardboard”, and there’s a lot of truth to it. 😉