this post was submitted on 24 Oct 2023

51 points (100.0% liked)

Chat

7498 readers

2 users here now

Relaxed section for discussion and debate that doesn't fit anywhere else. Whether it's advice, how your week is going, a link that's at the back of your mind, or something like that, it can likely go here.

Subcommunities on Beehaw:

AskBeehaw

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago

MODERATORS

remington

alyaza

Where will we all be(e) next year? (self.chat)

submitted 1 year ago by remington to c/chat

46 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[–] maegul@lemmy.ml 10 points 1 year ago (1 children)

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.

[–] Penguincoder 9 points 1 year ago (1 children)

why not have it federate?

Because activitypub is a hot mess and Lemmy's implementation on top of it, is problematic.

[–] maegul@lemmy.ml 3 points 1 year ago (1 children)

Because activitypub is a hot mess and Lemmy’s implementation on top of it, is problematic.

I believe you, but that doesn't quite answer whether it's worth it or not, software often being a hot mess to some extent anyway (said by someone who's never developed against AP/Lemmy)
I'm genuinely interested in your critiques ... do you have any prior posts of your or someone else's that you could point me to ... or a rant you're happy to drop here?

[–] Penguincoder 9 points 1 year ago* (last edited 1 year ago) (4 children)

EDITL Lemmy-UI deleted my !@#$#% links because I used the standard Markdown of less than and greater than symbols for a link.

1.)

2.)

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.

Rust development is hard, hard to learn, very hard to do right
Rust is not suited for a web application. Would you tell someone to go write the web application and web page in C/C++? Nope. There's a reason for that. Not suited to it. Square peg, round hole
There's always exploits being discovered. Rust handles some things better, but uhhh.. Go look at some Lemmy Rust code. Definitely still has vulnerabilities; Rust won't save you from yourself.

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 &lt;= 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.

[–] EthicalAI 3 points 1 year ago* (last edited 1 year ago)

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.

[–] potterman28wxcv 1 points 1 year ago* (last edited 1 year ago)

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.

[–] maegul@lemmy.ml 1 points 1 year ago

Thanks!

[–] EthicalAI 1 points 1 year ago

Reading your other links I don't understand why you take this stance

The problem with forking Lemmy is in starting from all the bad that is inherently there, and trying to make it better. That is way more work than starting fresh with more developers. IE, not using Rust for a web app and UI, better database queries from the start, better logging/functions from the start; not adding on bandaids. A fork of Lemmy will have all of Lemmy’s problems but now you’re responsible for them instead.

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.