Looks like KBin has an edge over Lemmy now in terms of monthly active users.
It's obviously a pretty silly thing, and is not in any way indicative of which project is "better" or more "long-term viable" or anything — instances of both federate with one another, and with the rest of fedi, so it's all one happy family.
That said, it's notable. KBin is a relative newcomer to the "Reddit-like fedi instance" game, and also does not have the tankie baggage.
Anyway, the more, the merrier!
KBin: https://the-federation.info/platform/184
Lemmy: https://the-federation.info/platform/73
Discussion on fedi: https://mstdn.social/@rysiek/110527049024028986
Why is php a bad thing in this case? It seems like exactly the kind of application that php is well suited for. Plus there's the maturity of php's major frameworks. While I'm not saying Rust is necessarily bad for building web applications, it's web frameworks must be less mature and battle tested. Plus, it seems like a lower bar to get community dev contributions for a php project than rust.
I can't speak for everyone, but I personally do not want to work with PHP ever again. I'm sure it's gotten better, but when I last used it (>15 years ago), the standard library was super inconsistent and performance was pretty terrible. It left a bad taste in my mouth, and I now prefer client-side rendering.
But aside from my personal dislike for PHP, here is why I prefer client-side rendering:
That said, for a federated system, it doesn't really matter that much since people can just increase the number of instances to help share the load. I just personally am not interested in helping with kbin, but I would be totally on board with helping with Lemmy.
Yeah, it shows you haven't used php in a while. Most of the gripes people have with it have been fixed over the years, and every framework encourages you to build an API-first app these days.
Sure, but the whole point of PHP is the templating. If we're going to avoid that (and kbin uses it), why use PHP?
The backend is going to be request heavy, so something with good async support is going to be a good bet and scale well. I don't know much about how modern PHP handles async, but it just seems like an odd choice for something with a high volume of small changes. Anything can work if you try hard enough, but at least for me, I'm more likely to get involved with Lemmy than kbin.
Well, to me Rust suggests that a given software project might be somewhat more performant, and somewhat more secure — but it all also depends on the developers, of course.
Well, that kind of sounds like the normal rust propaganda, don't get me wrong, I do think the language is decent, it's just tiring to see so many people just buying into and parroting some weird claims like "it's rust, so it's secure"
I like rust a lot, but it's definitely in the place Go was a few years ago, where people just assume "written in rust" = good for some reason.
Exactly :) That's what I mean as well, sure there are great things written in rust, but they are great because they are great, not because they are written in rust :)
I mean the reason people believe that is because it's a very explicit language. It knows what's in its memory at all times, and so at the lower layers it's more secure by nature.
As opposed to php, you're less likely to introduce a vulnerability by being sloppy with data sanitation - the language demands you tell it exactly the data structures you want it to put into memory. For that reason, the language is more secure - the parse json function is going to be less likely to be able to run rogue code maliciously embedded inside it than php, and if it does manage to do so, it's easier to write php to blindly open a hole in the system from inside an interpreter than it is to break out of or hijack the runtime.
Obviously that doesn't make it secure. It just means that all else being equal, rust is less vulnerable to a sloppy mistake at any given layer in the stack. Doesn't mean you can't make a logical mistake and open up a glaring security hole
And obviously you can write bulletproof php code, but every layer of the stack needs to be just as bulletproof. Including the interpreter and all your libraries - which historically were very much not bulletproof (it's definitely much more strict than it used to be, and I think I heard fb tried compilation and I'm not sure if that's become a thing, but it's generally is more secure than interpretation for similar reasons)
All that being said, humans are just dumb and sloppy. We write shit code, and we try to minimize the surface area for mistakes. Rust has a much smaller surface area than php
I'm very much aware of that, I have programmed stuff in rust as well, but claiming that it's secure and "better" because it's rust is just pr, believe me, I can write some really sihtty rust code.
I'm no evangelist for PHP, but I say use the tool that you know, when I make a new program I'm going to do it in nim, because it's the langauge that I have the most fun working with. It has mostly the same pros as rust, just with a lot nicer syntax and it's generally more flexible.
No shade on people liking rust, but this constant parroting of the same point by people who probably never even used the langauge is getting kind of old.