It’s a replacement for the Lemmy backend. It’s designed to be API-compatible initially so existing Lemmy clients, including Lemmy-UI can just plug right in.
It’s in Java, so there’s that overhead. I don’t speak for the project, but mostly, it’s less about “efficiency at all costs” and more about maintainability, being easier to contribute to / review, and having a less toxic development community. It’s got more developers working on it than Lemmy, and it’s in a language more people are familiar with (Java). It’s roadmap is also not constrained by the viewpoints of a small group of fairly, uh, controversial figures.
After the 1:1 compatibility phase is over, they’re both free to and planning to implement more features that the Lemmy devs either won’t or can’t be arsed to do.
It’s a replacement for the Lemmy backend. It’s designed to be API-compatible initially so existing Lemmy clients, including Lemmy-UI can just plug right in.
I see
How would this compare efficiency wise, because my understanding was that Lemmys backend was very efficient and that was a big advantage
It’s in Java, so there’s that overhead. I don’t speak for the project, but mostly, it’s less about “efficiency at all costs” and more about maintainability, being easier to contribute to / review, and having a less toxic development community. It’s got more developers working on it than Lemmy, and it’s in a language more people are familiar with (Java). It’s roadmap is also not constrained by the viewpoints of a small group of fairly, uh, controversial figures.
After the 1:1 compatibility phase is over, they’re both free to and planning to implement more features that the Lemmy devs either won’t or can’t be arsed to do.