Hello world!
We would like to start by saying thank you β€, no really π THANK YOU to ALL the moderators out there!
Without you folks, we would have no one to help keep our community safe and help build the communities both here on Lemmy.World and on other fine instances. To this end, we want to make sure your voices are heard π£ loud and clearπ£.
So, in the spirit of transparency, we would like everyone to know that we are looking to help out the folks working on Sublinks. Over the last several months we have grown to be more than just Lemmy.World. We've added platforms such as Pixelfed and Sharkey to help offer our users more diverse options for expressing themselves online. We still are very committed to Mastodon as well.
We DO NOT plan on moving away from Lemmy as a software platform at this time. Any changes in our core services would need to be discussed extensively internally AND externally with our community members. We firmly believe in the growth of the Fediverse and without the users, there would only be software, and that's no fun!
Sooo...
The Sublinks team has written up a little survey, which we feel is both thorough and inclusive. It covers a wide range of topics, such as user privacy, and community engagement, along with trying to gauge things that are difficult when moderating.
Also please be aware the information collected by this survey is completely anonymous. As many of us in the social sciences background know, if you want the REAL feelings of individuals, they need to feel safe to express themselves.
πModeration Survey HEREπ
Please feel free to comment in this thread, we will do our best to respond to any genuine questions.
We look forward to hearing from each and every one of you!
=Sincerely,
Fedihosting Foundation
PS ... also if this sounds like a corporate press release to you folks, we still punk π€ππ€
Considering that Lemmy is an open source project which is being built collectively by a big community, your comment sounds extremely strange. You are basically saying "we did not do enough testing for the 0.19.3 release, and we accept none of the blame for it."
Edit: The more I think about your comment, the more strange it becomes.. you guys are literally running the biggest instance, but rather than participate in the testing of big releases, you let smaller instances do it for you and then complain if nobody else is testing it at your scale. Your comments would be completely understandable if this was a paid product, but come on... Just think about it, would you also have this kind of approach for IRL community projects?
We did our testing, but we didnt scaled it up to be similar size of our main instance. There everything seemed fine, but when we upgraded the real issues have rissen up and were just breaking every setup we had.
We had some trust that other instances and developers had tested it at least by turning their instance on and report it, but didnt seemed so. Some issues isnt even caused the instance size. Some issues were documentation were just wrong and not noted it was experimental.
Of course we should have mirrored our big instance, but that would have increased the costs and would be time heavy.
What I'm wondering about is how you might start using a platform with a much, much smaller userbase, and expect that scaling problems won't be as bad or worse. With even less sister instances to get troubleshooting info off of.
I think they mentioned in another comment, but sublinks is developed in Java, so the .world team would be able to contribute more to the actual development/testing process (edit: since they aren't familiar with rust).
You know what's easier (and more productive) than starting a new project from scratch? Learning Rust. It's the future anyway.
That's the thing though, because it's kind of a paradox. If you had a single team working on it, then sure, it might be easier to just learn Rust. However, on an open source project, especially a volunteer driven one, that isn't necessarylily the case. Your average enterprise dev probably isn't even considering rust as an option yet, because it's still in early stages in terms of tooling and support infrastructure.
I made another comment in this post, but as it is right now languages like Java and C# make up significantly more projects/job positions than rust. If you want to get more contribution from volunteer devs, it needs to be in a language that devs are comfortable with. Most people won't want to learn a whole new programming language for a volunteer project when they're already working a full-time job in a different language. I explained this in the other post, but that's why I think having both projects is still beneficial. Sublinks and Lemmy can (hopefully) continue to exist at the same time and benefit from each other's development, especially if they stay API compatible. Sublinks will have a lower barrier to entry (thus maybe a quicker development cycle with more people involved), while Lemmy will help contribute to the validation of rust as a language for production code.
Also "rust is the future" implies that's the only programming language that is worth learning, which is simply not the case. Different languages are better at different things. There will never be a single language that's best at everything. Even for a specific task, multiple languages are good at doing the same thing. For example, Go, Rust, C#/any .NET, and Java/any JRE can all do REST services like Lemmy pretty well. Of those, I wouldn't even say Rust is the best choice, because its frameworks are all still pretty new.
Other languages are growing and evolving as well. Even old languages like Java and C++ have had significant improvements in their modern standards (Java records, C++ smart pointers, etc.). Hell, even COBOL got a new standard version as of 2023 (if I had to guess, this didn't do much for it though). Just because certain languages are bad right now doesn't mean they will stay bad forever.
Out of all those languages, I wouldn't choose C++, COBOL, or Java. Go, C#, and Rust all have benefits.
But regardless, the project exists and it's generally better to contribute to the existing project than to rewrite it from scratch. We didn't need two dozen Lemmy clients only for most of them to be abandoned, either. Our effort is limited, and fracturing it isn't going to do anyone any favors.
Lemmy works pretty well at a large scale. It's easier and more productive to bug fix and improve on the existing project in a new language than to reinvent the demonstrably working wheel in Java (of all things) that'll bring its own, brand new set of distinct issues.
But hey, at least it's not PHP.