- cross-posted to:
- fediverse@lemmy.ml
- cross-posted to:
- fediverse@lemmy.ml
Seems like an interesting effort. A developer is building an alternative Java-based backend to Lemmy’s Rust-based one, with the goal of building in a handful of different features. The dev is looking at using this compatibility to migrate their instance over to the new platform, while allowing the community to use their apps of choice.
I have a hard time believing that rewriting the backend from scratch would be faster than getting PRs approved on the main project.
Forks like this with one guy who “knows best” usually die a slow quiet death as they get left behind by the main project.
I think quicker feature development makes some sense, because there are more Java developers in the world and not many Java developers care to learn Rust. It’s easier to get contributions in more popular languages.
Rust is also awfully uptight about doing every little aspect right, which can be a bit annoying when iterating on program design, especially if you don’t have a lot of experience writing Rust code.
I’m a Java developer and I would much rather pick up Rust to join an active project than try to rebuild something that already works using a less-marketable language.
Sure, but it’s a lot more work for you to get to a point where you can be an active contributor.
Is it really a lot of work for an experienced dev? I can pick up most new languages in a day or 2 unless it’s a total paradigm shift.
1-2 days is enough to learn the basics, but I doubt you’ll be as nearly as productive as with something you’ve been using for years. Keep in mind that new languages also mean new frameworks, etc, some which take years to actually master, but at least months to get a good handle on them.
Also, from my understanding, Rust is a bit of a paradigm shift.
I think how quickly this project has gotten to near feature parity is a testament to how slow Lemmy development has been. Think about scaled sort (a feature that has been hotly requested since the migration) and how long that took to get merged in. A sort should not by any means be slow to implement.
IMO slow development isn’t necessarily a bad thing.
I like that there was a two month period for apps to adopt the new login mechanism and that they smoke test releases for a fair bit on lemmy.ml before releasing to the world.
That said, a few months ago I wanted to do a light fork of Lemmy to proof out a few very minor things on my mental wishlist but just haven’t had the free time to meddle with Rust.
Quite the opposite, often it’s a benefit as you don’t end up wasting time and changing code for features where you don’t actually know yet whether your current usage demands or supports them. There’s a lot of genefit in not moving fast and not breaking things. Mostly that, well, you don’t constantly break things.
Sure but even just recently there was the example of breaking federation over Christmas. Some of those issues persist through 0.19.3 which came out today
Yeah, that was definitely annoying. I would’ve preferred to have some kind of official workaround but I figured something out that got me through until the updates.
I probably lean too hard into forgiveness on this stuff but I know a number of open source devs who have burned out for various reasons this past year and would much rather see slow development than risking a rush towards burnout.
Sure, if the sort key is something readily available. But for scaled sort they have to compute relative size/activity of the communities the specific user is in. The cost isn’t the sort, it’s computing the metric.
I’m not talking about the literal sorting algorithm. Pretty sure scaled sort is exactly one more operation than hot.