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. 😉
That analogy really drives the point home. Basically, lemmy already has a built-in advantage due to the tech they went with. But like any program/machine, it’s only as good as the people behind it. Thank you for the answer.
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.
Wow, I didn’t know that about the Lemmy devs, that really sucks…
Yeah… I had heard of it as a rumor, so I doubted it for a little while, until I was shown the receipts. https://lemmy.world/comment/562635
It really is disappointing.
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. 😉
That analogy really drives the point home. Basically, lemmy already has a built-in advantage due to the tech they went with. But like any program/machine, it’s only as good as the people behind it. Thank you for the answer.
Exactly, and my pleasure!