In this post I am speaking as a Beehaw fanatic and not as an admin. That is why it is placed in the chat community. To be clear, I am not speaking on behalf of the Beehaw admin team nor the community as a whole.
Currently, we have $5,430 that is in our collective purse to be used to further this endeavor. When I take a step back, and look at that amount of money, I am humbled. That is hope…it is an expression of where we want to go and what we want to preserve.
You may be wondering where we are with the testing of alternative platforms and any other considerations.
The testing phase, as far as I can tell, is over. We are, I believe, in a stage of digesting all of it. And, I have a feeling, that we are holding out hope that there could be other options we haven’t encountered yet.
I appreciate the patience of everyone involved and I don’t want to make a hasty decision.
Thankfully, we have had persons such as PenguinCoder to rescue us from the huge Reddit exodus and all the technical problems associated with the Lemmy software platform that we rely on right now.
There have been whispers that PenguinCoder could be working on a new platform for the Beehaw project.
Thank you all for grabbing onto our northern star, be(e) nice, and running with it.
Yea, totally with you. Thing is, as trite as it is to say … things change and you can’t so easily go back to the way things were.
Sure, 20 years ago it may have been fine to jump around various forums. But we’ve now had 10-15 years of the opposite of that, which was popular for a reason. While I’m nostalgic for the pre-facebook internet too, part of the appeal of federation to me is that it’s a “why not both” solution. The convenience and power of bringing things together into a more coherent and manageable toolset or interface is just too attractive to put it aside. In fact, I’m often critical of the fediverse for not doing a better job at making easier for the user to unify their experience.
Beyond convenience … something of the “chance encounter … I just saw this random thing on my big social platform” experience may be something many do not want to lose and which requires interconnectivity as the big social platforms and federation can provide.
Additionally, the internet and our experience on it now is probably just more than what was the case 20 years ago. More web pages, more tools, more logins, more devices, more apps … just more things to manage and navigate. Against that backdrop, going back to complete segregation just may not make as much sense as it did then.
Software wise, developing a new platform is software work, one way or another, so … why not have it federate? I’m sure it’s more work but also maybe worth the payoff?
All that being said … reality is that the internet is pretty fragmented at the moment I’d say and more than I feel many understand/appreciate/admit.
Because activitypub is a hot mess and Lemmy’s implementation on top of it, is problematic.
1.)
https://overengineer.dev/blog/2019/01/13/activitypub-final-thoughts-one-year-later.html
https://gist.github.com/jdarcy/60107fe4e653819138396257df302eef
2.)
https://beehaw.org/comment/1178543
https://beehaw.org/post/7278522
https://beehaw.org/post/980868
https://beehaw.org/post/7776438
My comment on a deleted post
These are my opinions, probably not shared with others and surely not the end all be all to ‘why not Rust?’
Rust is hard. Rust is slow to iterate with and compile. Here’s a highlevel overview of the things you’d need to learn to effectively understand Rust code; not even speaking to learning enough of that to write it. Rust gets touted as secure, and it is more secure than other low level languages like C/C++. That does not make it invulnerable to exploits. It gives a false sense of security to developers who think My app can’t be hacked, it’s written in Rust!!. While Rust is better at memory management and protecting against run time errors related to memory issues, that doesn’t make it 100% safe. That removes almost one class of potential exploits, not all of them, and can’t protect the developer against other developer created issues. Rust code is still written by people. People still write insecure code even in Rust. Computers are dumb as hell; but fast. People are smart as hell, but SLOW. Combine the two and you get stupid things faster; not smarter things better.
Something like Golang is much better choice for development of a web service that has sane API handling. By the time to add in more error handling, more type checking, more passing around of this function or that data, and more checking it on the sender and receiver side…etc. By the time you’re writing Rust safely and correctly; it is much slower than what you may be lead to believe.
Go is primarily designed for speed of development (including compilation times), rather than speed of execution. Go programmers tend to value clear code over fast code. Why does a microsecond longer matter for a website? Maybe in some backend PLC land there’s a damn good use for that performance. For a networked web application; it’s a pointless metric. That is not going to be your bottleneck.
Rust is hard to understand just reading it let alone determine why it’s doing something.
Rust
fn does_what(n: u64) -> bool { match n { 0...1 => false, _ => !(2..n).any(|d| n % d == 0), } }Golang
func doesWhat(value int) bool { for i := 2; i <= int(math.Floor(float64(value)/2)); i++ { if value %i == 0 { return false } } return value > 1 }Not talking about the functionality merits of the two, but in comparing the _code itself. One of those is much easier to determine what’s going on and what it should be doing versus the other. I don’t feel like fighting my code. Programming is a tool to help. If it takes more work to use the tool to achieve your goal, it’s the wrong tool. Rust is the wrong tool for web development.
Meh, I’ve programmed in both. Rust is “hard”. I wouldn’t ask a company to write in it, because it might be hard to get devs for it. However, open source is different. Rust is not hard enough for most developers to learn, and most developers love it when they learn it. On top of that, GoLang is practically an expert in hidden, annoying bugs that rust almost categorically eliminates. Golangs panics don’t backtrace unless you write them in a certain way, you have to know the golang “culture” of error handling, and then without a good match statement or ? macro you are left with ifs under every goddam line of code to do your own manual error checking. Golang goroutines are not as intuitive as one might think with how they close when the scope they come in from closes and their channel patterns. And the “context” passing takes a long time to learn how to do right. It’s an intuitive language at its core, its docpage being one page, but it’s culture is like python’s, needing a year or more to really know what best practices are. I tbh think they are just about exactly as hard as one another, but one, golang, leads to more bugs. Compile time is not that important when you can ensure that at compile time the thing will run.
Refactoring rust sucks, but by keeping your structs small you can usually avoid it.
Thanks!
Reading your other links I don’t understand why you take this stance
Assuming you are an experienced developer, as am I, I have said this almost a thousand times. It’s almost always wrong. Lemmy’s codebase is decently clean and organized, and seems to be around 50,000 lines. All you are going to get by forking is having to rewrite a bunch of CRUD.
The other option is writing tools and plugins to interface with Rust’s API. Lastly, as long as you keep your history clean on your fork, you can continue to rebase onto the original. I think rewriting is just a terrible idea.
Anyway, if you do end up leaving lemmy, why not just go to one of the many standard forums? Discourse is nice.
About your specific example I find the Rust code to be much simpler to understand than your equivalent Golang code…
To understand the Rust code I just have to understand each case. 0…1 returns false. Ok. 2…n returns true iff no divider was found between 2 and n-1. Ok the function is primality test
The Golang code is much harder. I do not take into account the division by 2 because its not part of the original Rust code.
A for loop starting at 2 that look for divisors. Then the return value > 1. Why is it OK to just return
value > 1? Oh that’s because the loop did not return. Why did it not? Either no dividor was found or we did not get into the loop at all. If value > 1 we have the guarantee the loop was executed so it’s really a primal number. If value <= 1 it is either 0 or 1 which are not primal. Ok, so we return value > 1.I think people dislike Rust because it has a lot of functional languages constructs and people are not used to code in functional languages.
Whatever you fight in Rust you end up saving time by avoiding runtime bugs that would have plagued your productivity anyway. I’d much rather have a language with a hard entry but with solid and maintainable code rather than fast-written spaghetti that no one knows what it is supposed to do 2 years after.