• 7 Posts
  • 58 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle









  • All that being said, a rewrite is still harder. Think how much work kbin and lemmy have put in. Think of all the apps that have been developed around them. It’s still sql driven, meaning you can easily write any kind of moderation tool you want in any language of your choice.

    I think the Rust vs Golang question is just opinionated, and until there’s something better than activitypub there’s nothing even a fork can really do about those issues, and I’d really want the FSF to deal with those kinds of complaints.







  • 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.


  • 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.


  • I mean Rust is a godsend as a decision for the language to use. Kbin for example uses Php, which means I’ll never contribute to it. Other alternatives would be like Python, Node, or Golang, but why? The first two won’t scale as well on a single node and all will have worse static typing (especially Golang). When I examined the code, it seemed like a standard sql+rust stack. I can’t imagine anything even major needing changing, let alone a full rewrite.