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:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
20 years ago we went to different forums and had different types of discussiuns on each. I guess I don't really understand why we need the whole internet on one site?
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
Golang
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!
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.
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.
Back then, there may have been fewer topics, but there was discussions all abound. On communities like this one, the discussions are much fewer despite there being a fair amount of topics. I need more things to consume to pique my interests because the comments are few and far between. Sure there are a few posts that get a fair amount of comments, but there's not enough of that.
I was more meaning... if Beehaw moves off lemmy, why do you have to choose between beehaw and lemmy? Por que nos los dos?
Because beehaw is my ideal home base for lemmy. The comments are better here, and it's nice to be able to venture out to the greater fediverse from here. Without beehaw, I'd care less about lemmy as a whole.
Already have a thousand logins for sites, personally I'm not interested in adding another one. Plus it's obvious when you have time to kill that there is one app you prefer over another, it makes sense to keep aggregation services like this federated into one feed.
This is true but I think we need to remember the internet with less rose colored glasses as well.
There was a lot more decentralization to the older web, but most general discussion still revolved around a handful of big name message boards. Sure you had more smaller forums for specific hobby's like photography or knitting , but there was usually a big photography forum and a big knitting forum and a bunch of mostly dead ones.
Then there are the communities we all fondly remember. Our message board of international internet friends, but slowly but surely those message boards started to just die off as users left and moved on and discussion dried up.
I feel like federation gives us a sort of best of both worlds in theory, though in practice I'm not sure if it will work like that.
Also I feel like regarding beehaw specifically, as it exists this community is broad enough that it benefits from a bigger user base, but understandably its hard to maintain the standard they want. Overall I think the issue for me when it comes to following beehaw where they go is that Im here more for the general stuff and I imagine that the shift will lead to a big reduction in activity in conversation about say technology and news and health and the like. I remember how smaller message boards got on and while beehaw is currently one of the bigger more active lemmy instances I suspect that the majority of users wont follow. Even now most of the content we have sits at less than 10 replies.
I wish everyone luck, and I know the founders were on lemmy long before the reddit bump changed things so they are happy and able to continue on as a smaller more compact entity, but I'm probably not going to move on. That said it's a shame because lemmy discourse and attitude is one of the better parts of lemmy so its very possible that without beehaw I drop lemmy as well(outside I guess mander and @startrek stuff maybe)