I will no longer be able to assist with development nor debugging actual issues with the software… Quite juvenile behavior from the devs. It stemmed from this issue where the devs continuously argued in public by opening and closing an issue. Anyway, thought I would keep y’all apprised of the situation, since these are the people maintaining the software you are currently using.

  • @[email protected]
    link
    fedilink
    32
    edit-2
    6 months ago

    Lemmy needs a fork, if only to kick the devs into gear with regards to actually working with/listening to the community. At this point a significant number of users have been lost because the devs have been largely unable to capitalize on previous waves on growth due to slow development. It’s one thing if it’s just a couple of devs working on the project and trying their best, it’s an entirely different thing when a couple of devs are shutting out large numbers of contributors (frequently subject matter experts which they desperately need at this point) over relatively trivial issues. This isn’t the first time this has happened and it won’t be the last. Mbin is reviving Kbin as a project and we need something similar for Lemmy.

        • ShittyKopper [they/them]
          link
          fedilink
          English
          4
          edit-2
          6 months ago

          Yup.

          In fact, you don’t need to be based on Lemmy’s codebase in order to be compatible with Lemmy. See: Kbin/Mbin, https://azorius.net, https://narwhal.city (which seems to be lotide’s flagship?), or heck, Mastodon (although the interoperability UX there isn’t the best)

          Building on Lemmy would make things significantly easier, especially regarding the quirks of Lemmy’s implementation of ActivityPub & FEP-1b12 though, so a fork would be the path of least resistance.

          The fedi has a long history of forks for a variety of reasons. Hell, Misskey alone has like a bajillion forks to the point where it’s a meme how many of them there are, and yet they’re all compatible.

          • @[email protected]
            link
            fedilink
            26 months ago

            In fact, you don’t need to be based on Lemmy’s codebase in order to be compatible with Lemmy. See: Kbin/Mbin, https://azorius.net, https://narwhal.city (which seems to be lotide’s flagship?), or heck, Mastodon (although the interoperability UX there isn’t the best)

            Of all the misplaced priorities by the dev team I really think this is one of the biggest. If they just fixed authorized fetch Lemmy would almost certainly be the goto host for groups among the broader Fediverse.

      • @[email protected]
        link
        fedilink
        236 months ago

        Let’s not forget, there is a very real sense in which building the communities is harder than building the software. Anything that can be done to preserve existing communities is a win in my book.

      • interolivary
        link
        fedilink
        26 months ago

        Yeah, I’d tend to agree. Lemmy’s codebase is pretty atrocious and it looks like the main devs really don’t know Rust well enough, and honestly they don’t seem to be very good at developing a service like this. There’s just no reason to go with Rust for a web service project like Lemmy (despite what Rust cultists will undoubtedly soon come to tell me), it limits the amount of people who can work on it due to not being as commonly used in this particular field, and it’s honestly baffling how they managed to use Rust and make the service as slow as it is – speaks volumes of how shitty the design is, and that they’re doing something fairly stupid with their database.

        • @philm
          link
          76 months ago

          despite what Rust cultists will undoubtedly soon come to tell me

          And here I am :)

          There’s a lot of reasons to go with Rust (and least of all performance), especially as web-backend. Top-notch libraries/ecosystem (I work extensively with all kinds of programming languages and most others suck in one way or the other). At this point I dare to say that it has the best ecosystem in this regards. Also a static type-system only being exceeded by Haskell (when talking about general purpose languages, that are actually in use), which makes projects maintainable by a lot of people, especially relevant for an open source project. There’s a reason why a lot of high quality projects are either rewriting or starting in Rust or are thinking to switch to… Etc. don’t want to throw more Rust evangalism at you, since there’s a lot to just google and learn…

          Anyway, there were a few changes lately that made federated lemmy better (with the last release especially), the initial bugs I accept. But I agree, they aren’t veterans from the valley with multiple years of experience, just a bunch of idealists that had an idea and were persistent enough for years to implement it, I certainly have respect for that. What I don’t like, is that they are moderating a little bit too much, not being mostly community focused (among others, to avoid forks). But bringing a federated link aggregator like lemmy to the place where it currently is, at least takes quite a bit of time… So a fork (if really necessary) sounds like the most likely way forward…

          • interolivary
            link
            fedilink
            36 months ago

            I seriously doubt Rust has the best ecosystem for web backend development, and I seriously doubt anybody claiming that knows what they’re talking about

            • @[email protected]
              link
              fedilink
              5
              edit-2
              6 months ago

              I mean, “best” is infinitely subjective. I would be inclined to think any anyone who says “php is the best backend software ecosystem for web” doesn’t care much about programming and are really only in the business of making money. Rust is at the creative forefront right now, it makes sense a bunch of pissed off people chose rust to make a reddit clone, it would be challenging to draw passionate engineers to a php or java project; it gives a way to draw more helpful attention (which they are as we now see squandering)

              • @philm
                link
                26 months ago

                Yeah best is probably not the “best” wording and a little bit provocative, but it’s the “best” ecosystem I have found so far (and I squabbled around with like ~10+ programming languages, often at a deeper level). I’m mostly talking out of a development-experience + quality of software standpoint.

                I’m very happy to be proven wrong, or be given a different direction (but C# or JS/TS are definitely not the languages/ecosystem I want to be confronted with, or even maintain systems in it…)

            • @philm
              link
              46 months ago

              Sure you can doubt me as much as you want (and this is probably a healthy attitude). I tend to educate myself, and learn from experience (and that I dare to say, I do have…). As you may have guessed, I really recommend looking into it, there’s so many good design decisions with Rust (and the ecosystem). As a starting point/library: axum would be the web-framework I’d recommend to use (as it uses Rust quite idiomatically). And for e.g. service communication via grpc, tonic is quite nice. As database abstraction layer the last time I have used sqlx which was quite convenient to use. (So far with a “classic” web-stack). And rust-analyzer is probably the best language server I have used (and felt the fast development over the time (with “successful” switch of the maintainer), which speaks for itself as well…).

              Btw. it also really depends on what you actually mean with “web backend development”. I.e. “just” writing a web-server that takes connections via HTTP or something deeper the stack…

              • @ericjmorey
                link
                36 months ago

                I like your attitude and approach to this conversation. Thanks for not escalating into a useless argument and making the discussion educational.