What software stack would you have chosen for Lemmy?

Comments

• key@lemmy.keychat.org ⁨1⁩ ⁨year⁩ ago

  Backend in Javascript (node) and frontend in PHP (web assembly), the only sane way.

  source

  • Elderos@lemmings.world ⁨1⁩ ⁨year⁩ ago

    The database shod be made in Flash.

    source

    • rikudou@lemmings.world ⁨1⁩ ⁨year⁩ ago

      Nah, database as one huge JSON stored in local storage. Wait, did I accidentally invent MongoDB in a browser?

      source
    • JWBananas@startrek.website ⁨1⁩ ⁨year⁩ ago

      OpenSilverlight would like a word.

      source
    • AnUnusualRelic@lemmy.world ⁨1⁩ ⁨year⁩ ago

      Just use Cobol. Lots of Cobol developers are idle these days.

      source
  • SatyrSack@lemmy.one ⁨1⁩ ⁨year⁩ ago

    Backend in Excel

    source
• Olap@lemmy.world ⁨1⁩ ⁨year⁩ ago

  So Rust is capital H Hard to hire good developers. There just ain’t enough with experience in not only the language, but service management, the rest of the SDLC, SLAs, getting the best out of Diesel and knowing DBs, and the grizzled nature needed to be leading teams etc. There just isn’t enough of it in production to have built up this industry level that python, js, php, c#, and java have. Typescript is also pretty niche still, and thus has similar problems, though not to the same extent.

  And I’ve noticed pretty much every backend dev would like Rust, every front Typescript. And fullstack will learn and run everything and anything anyway. And so this is a temporary problem. Early adoptors, like lemmy, will see more people contribute, more learn, more launch more stuff. And that starts with open source projects.

  And thus: I’d make exactly the same decisions. Lemmy isn’t a bank, it’s more a start-up, it doesn’t pay well, it has to attract on other benefits. Attracting volunteers might be easier in desirable languages, will certainly be easier in ten years time say than Rails, Play, or Laravel might be. CV fluffing from OS contributions is a fantastic way to make yourself more marketable, and who doesn’t want TS/Rust on that CV?

  source

  • shagie@programming.dev ⁨1⁩ ⁨year⁩ ago

    Attracting volunteers might be easier in desirable languages, will certainly be easier in ten years time say than Rails, Play, or Laravel might be. CV fluffing from OS contributions is a fantastic way to make yourself more marketable, and who doesn’t want TS/Rust on that CV?

    For much of its development life, Lemmy devs weren’t soliciting (or encouraging) help from volunteers. github.com/LemmyNet/lemmy/graphs/contributors shows it to be a very “just two person with no one else” project.

    source

    • Olap@lemmy.world ⁨1⁩ ⁨year⁩ ago

      AGPL means anyone is free to fork it I suppose. But they also picked what the pair of them wanted. And could both walk into many a high paying role with this exposure. I hope they do expand the contributors list though, bdfl is a great OS governance model imo

      source
• koka@lemmy.world ⁨1⁩ ⁨year⁩ ago

  I think Rust is a perfect choice here. Considering the investments of the Linux kernel, AWS, Microsoft and so on I think Rust is a future-proof bet.

  That said it think the programming language is not everything. It seems to me that lemmy was written under the assumptions that there will be a lot more hosted instances that will fedrate but a lot of load seems to centralize on a handful of instances now (i.e. lemmy.world).

  To support these it could make sense to rethink the system design to something that offers better support for high-load and high-availability scenarios.

  source
• foo@withachanceof.com ⁨1⁩ ⁨year⁩ ago

  Rails. Of course, I’m biased because it’s what I know the best, but also because Mastodon is written with Rails so in terms of getting more contributors from a similar project I think Rails would have been a good choice.

  I also looked into helping with Lemmy development, but ran into the same problem you’ve described: I don’t know anything about any parts of the stack. I run my own instance so I can run and debug it well enough, but actively working on new features/bug fixes would require more time to get up to speed than I can put in currently.

  source

  • AureumTempus@lemmy.world ⁨1⁩ ⁨year⁩ ago

    [deleted]

    source

    • foo@withachanceof.com ⁨1⁩ ⁨year⁩ ago

      To each their own. I don’t fanboy frameworks, they all have their pros and cons. What you specialize in for a personal professional career is different from what you may choose for a free software project though. Plus, I’d argue there’s definitely downsides to the JS ecosystem as well but also frameworks you know should not dictate your career prospects. I get this all the time in interviews and career development talks. If you consider yourself a web developer getting up to speed with a new stack or framework shouldn’t be an insurmountable task. The nature of web development is that it’s constantly changing. Feeling stuck with Rails vs. Django vs. React or whatever else means your skills are not keeping up with the market; it’s not a fault of the framework. The only constant in this line of work is change.

      That said, Rails isn’t going anywhere. JS frameworks are the hot thing (for whatever reason, I despise them for all sorts of reasons, but that’s not the point) for many new companies/projects, but there are very large companies whose products are built on Rails: Shopify, GitHub, GitLab, Zendesk, etc.

      There’s too much radical changes. First from sprockets to webpacker and then import-maps and propshaft. And then the in-built Hotwire is so hard to grasp.

      Would this not be viewed as adapting and keeping up with the trends? Webpack is terrible, but that’s what the JS world went with so Rails adopted it. Now there’s ESbuild, import-maps, and Hotwire. Rails supports all of them (import-maps, by the way, is a web standard, not a Rails specific thing… and I love using it). You don’t need to use them and can pick which works best for your product/project. That’s a benefit in my opinion.

      I also used my Rails knowledge to contribute to GitLab because I was misinformed that open source contribution would increase my prospective of getting hired. I contributed for around six months, got rejected multiple times, and then stopped all contributions to GitLab.

      GitLab certainly has that reputation. I don’t see how that’s a knock against Rails though. Shitty companies will be shitty companies regardless of what stack they use. Personally, I never contribute any code to projects that have a commercial organization behind them. If it’s not GPL licensed (or similar) you’re probably getting screwed by spending your time working on it.

      source

      • -> View More Comments
    • railsdev@programming.dev ⁨1⁩ ⁨year⁩ ago

      Rails definitely has its downsides but your experience in the job market is strange to me.

      Ruby on Rails developers these days are in short supply. During the pandemic I secured two jobs (first one sucked) in Ruby on Rails developer positions. Back in 2017 I took a coding bootcamp for Django/Python but when I saw how little those jobs paid I stayed with Rails.

      There are a lot of hectic changes but thank God for those. If it were the same as it was 15 years ago there wouldn’t be a chance anyone would use it. The hype crowd got scared off in the early days but modern Ruby is pure bliss to work with.

      source

      • -> View More Comments
  • railsdev@programming.dev ⁨1⁩ ⁨year⁩ ago

    I was going to say Crystal. I have something like 10 years’ development experience in Ruby on Rails but honestly I can’t say I’d want to use it with type safety in mind.

    Crystal is just dying for people to jump on board and a whole federated social platform would’ve put it in the spotlight. It’s a fantastic language that just happens to be lacking libraries.

    source
  • Dark_Arc@social.packetloss.gg ⁨1⁩ ⁨year⁩ ago

    Rails is terrible. For something like Lemmy I’m confident it would just fall over (or require a much higher hosting burden). There’s way too much data to render and retrieve in a system like Lemmy, the caching systems for JSON shuck (hello jbuilder caching objects instead of json), Ruby performance is awful, there’s no mitigating factor to allow efficient blocking on IO bound requests (like coroutines or fibers), Ruby used a non-compacting garbage collector so it’s subject to heap fragmentation and wasting memory, there’s no static typing (or even type hinting), the Ruby ecosystem is built on Rails alone at this point (few if any libraries to make use of), the principle of “developer happiness” results in the need for tools like Rubocop to “resolve” invented problems WRT “how do you style X in a particular context” (among other things), and to top it off the framework makes doing the wrong thing easy and the right thing harder (Rails apps are so prone to N + 1 database queries).

    It’s also a ridiculously hard thing to hire for because basically nobody teaches Ruby or Rails. There’s a very limited pool of Rails experts.

    If some of that has changed I’d love to know, but after working in rails for ~3 years… I have no love for it.

    source

    • foo@withachanceof.com ⁨1⁩ ⁨year⁩ ago

      For something like Lemmy I’m confident it would just fall over (or require a much higher hosting burden). There’s way too much data to render and retrieve in a system like Lemmy, the caching systems for JSON shuck (hello jbuilder caching objects instead of json)

      Well, it seems to work well enough for Mastodon. I’d also point out that there are websites far larger than Lemmy using Rails at scale (Shopify and GitHub being the primary examples). It scales quite well.

      Ruby performance is awful

      Without benchmarks, this is a subjective statement. Ruby 3 is quite speedy now, at least I find it to be. I think this “Ruby is slow!” stereotype is left over from before Ruby 1.9 when YARV was introduced. Is it as fast as a native language? No and it never will be, nor will any other interpreted language. But this idea that Ruby is somehow the slowest possible interpreted language has not been true for a very long time now.

      there’s no mitigating factor to allow efficient blocking on IO bound requests (like coroutines or fibers)

      I’m not entirely sure what you mean by this, but Ruby introduced fibers a while ago.

      Ruby used a non-compacting garbage collector so it’s subject to heap fragmentation and wasting memory

      Not true anymore. Ruby has had a compacting GC for a while now.

      there’s no static typing (or even type hinting),

      You can use RBS (built into Ruby) or Sorbet (third-party Shopify project) for this if you want. Or don’t, I personally prefer Ruby’s duck typing. I don’t think a language using someone’s preferred type system makes it “terrible” just because it’s not what someone likes. Other people are perfectly happy with it.

      the Ruby ecosystem is built on Rails alone at this point (few if any libraries to make use of)

      Ruby being a one-stop-shop for Rails has been a criticism of it for years. I’m not sure how that’s a knock against Rails or Ruby though. I personally write all sorts of non-Rails things with Ruby as I love the syntax and greatly enjoy writing Ruby code over that of, say, Python. To each their own though. There’s Sinatra, Jekyll, Fluentd, Chef, etc. all written in Ruby.

      the principle of “developer happiness” results in the need for tools like Rubocop to “resolve” invented problems WRT “how do you style X in a particular context” (among other things),

      I personally love the configurability that Rubocop provides. Some people like the “one true way” of formatting for languages like Go (which also for some reason thinks single letter variable names everywhere is a great idea), but other linters like Eslint for JavaScript have the same level of configurability as Rubocop. Alternatively, just don’t use them. Rubocop is not something you need to use to use Rails.

      and to top it off the framework makes doing the wrong thing easy and the right thing harder (Rails apps are so prone to N + 1 database queries).

      Drop in gem that will automatically solve 99% of N+1 issues: github.com/clio/jit_preloader

      It’s also a ridiculously hard thing to hire for because basically nobody teaches Ruby or Rails. There’s a very limited pool of Rails experts.

      Again, subjective statement here. My company has no problem hiring Rails devs. Granted, we operate on the idea that any good engineer can get up to speed with a framework in a reasonable amount of time. I don’t believe in the “you are only worth the frameworks that you know” idea. Give me three months and I’m confident I could be proficient & competent with any web framework. Those are the people I want to hire. Not the person that’s going to be afraid to jump into something new because they’ve never worked with it before.

      source

      • -> View More Comments
  • cerement@slrpnk.net ⁨1⁩ ⁨year⁩ ago

    and at some point in the future, the possibility of upgrading from Ruby to Crystal …

    source
• abhibeckert@lemmy.world ⁨1⁩ ⁨year⁩ ago

  I’d have gone with PHP. Modern PHP is really good, all the tools are mature, the few drawbacks it has are well understood and easily worked around, and it’s an easy language to learn with a huge community of people who already know it.

  source

  • falsem@kbin.social ⁨1⁩ ⁨year⁩ ago

    So, kbin then?

    source
  • Asudox@lemmy.world ⁨1⁩ ⁨year⁩ ago

    PHP is dead. Why not use TS.

    source
• Nerd02@lemmy.basedcount.com ⁨1⁩ ⁨year⁩ ago

  The backend is quite alright. The Rust backend makes it indimidating to approach, but I know it has many advantages.

  The frontend could use LOTS of changes. I don’t like Inferno, it’s messy and confusing to work with. Instead, I would have opted for a Svelte+Tailwind stack for the UI.

  source

  • OffByOneError@programming.dev ⁨1⁩ ⁨year⁩ ago

    Svelte is such a pleasure to work with.

    source
• asyncrosaurus@programming.dev ⁨1⁩ ⁨year⁩ ago

  I’d use what I’ve been experimenting with exclusively on personal projects: htmx, AlpineJs and Razor Pages on PostgreSQL AKA the HARP stack. Obviously, a hilarious acronym was needed.

  Which might sound esoteric and hipster, but I’d contend it’s pretty close to how we were building websites for decades before the cult of the SPA took over. For those not in the know, HARP is built with no fe frameworks, everything is rendered server side and html is swapped in the DOM on the fly. Htmx is a very tiny js library that makes backend requests to the server, and renders the returned htmx within the current page. AlpineJs is a client-side js library that acts like a modernized and simplified jQuery. Razor Pages is part of the ASP.NET web framework that runs on .Net, and produces html from Razor templates coded with C#. My professional work is on SQL Server, but I like PostgreSQL as the runner up because I’m not paying mssql out of my own pocket.

  I’m wouldn’t be concerned with hiring since I’d mostly just need C# developers with some designers. .Net developers are a dime a dozen, and many are seasoned vets with 15+ years experience building with .Net. it’s easy to build a career with, so few are running around flipping frameworks every few hype cycles.

  But I might have just shown my age and bias.

  source

  • mordack550@lemmy.world ⁨1⁩ ⁨year⁩ ago

    The behaviour you described is very similar to what Blazor is. No frontend framework, and the DOM updates are rendered on the fly. I’m using it a lot and it’s very good.

    source

    • asyncrosaurus@programming.dev ⁨1⁩ ⁨year⁩ ago

      I like Blazor and use it exclusively at my work (usually to build the same type of stuff I’d use a HARP approach in a personal prj).

      Blazor is awesome, but really is attractive to backend .Net developers more than anyone else. However, Blazor has a bunch of downsides: Blazor Server is too chatty to build scalable public facing webapps. Blazor WASM has a massive initial payload, which makes it slow and heavy.

      Also, it just really falls into being overkill for so much stuff on the web. Half the shit I’m paid to build with Blazor would be faster and cheaper with just some htmx. Most SPAs are attempting to build a sand castle with an excavator.

      source

      • -> View More Comments
• asdfasdfasdf@lemmy.world ⁨1⁩ ⁨year⁩ ago

  Definitely would have kept Rust, at least. Rust is one of the fastest growing languages out there (maybe fastest or second fastest), and it’s incredible for the majority of application domains, not just performance related.

  source
• ono@lemmy.ca ⁨1⁩ ⁨year⁩ ago

  I’m mainly glad they chose something with decent memory safety. This is important to me in systems that face the network or process external data.

  The issue of attracting contributors is a funny one right now. We happen to be living in a time of plentiful new and interesting languages. Rust, Nim, Vale, and Elixir, for example, have all caught my attention by bringing things to the table that older, better-established languages don’t do as well. In order to benefit from them, and potentially help shape them into tools that benefit us even more, we have to use them. This is how we build a better future for ourselves, and for our field. IMHO, this is more important than maximizing the number potential contributors on every project. As a fairly new project, Lemmy is in a good position to make this trade-off.

  (Also, having fewer contributors generally makes a project easier to manage, so the downside is not necessarily all down.)

  Rust probably wouldn’t have been my first choice, but that’s only because my early impression is that it seems ugly and awkward, so I don’t think I would enjoy using it. That doesn’t make it an objectively bad tool for the job.

  On the front end, I just wish it was less reliant on JavaScript, remaining functional when scripts are disabled in the browser. Outside of that, TypeScript seems like a fine choice.

  source
• starman@programming.dev ⁨1⁩ ⁨year⁩ ago

  Interesting question. I’d choose .NET backend and Vue + Nuxt frontend and REST API between them.

  source
• Empathy@beehaw.org ⁨1⁩ ⁨year⁩ ago

  I’d honestly choose a similar stack for the back-end. I have limited experience with Rust, but my impressions so far is that it’s a language that allows you to make changes with confidence that they’ll work. I feel like starting something in Rust is somewhat difficult, but contributing is relatively simple.

  For the front-end, I don’t think the choice is as important, since I think that by virtue of being federated and being able to have multiple front-ends, it would almost be better for the front-end to be managed by other parts of the community. And I say that as a primarily front-end/developer-experience dev.

  source
• RonSijm@programming.dev ⁨1⁩ ⁨year⁩ ago

  I read someone saying that the lack of contributors was due to the software stack being unconventional and takes people a while to get used

  I don’t think the software stack does matter that much. I’ve downloaded the Lemmy source and ran it from source, and my main caveat with it is the structure. I would have liked to see a much more modular design, with an add-on kind of system. Now, when an instance owner wants to add a feature, they only options are either to: Try to get their specific feature into Lemmy main, or create a specific Lemmy fork.

  The entry level to just “create your own Lemmy addon” is much smaller than to try to get something new into the main repo.

  For example, a great system is something like Home Assistant - Where this is a structure of “Addon-Repo” and “Addons” - with a Main Repo and you can add your own custom repo, or just install from .zip if you want that for some reason. Kind of similar as something like Nuget

  If people could “contribute” with their own standalone things instead of having to PR stuff into a repo, you’d get much more contributions and user created add-ons

  source

  • Miaou@jlai.lu ⁨1⁩ ⁨year⁩ ago

    Do we want to end up with a WordPress situation however? Gate-keeping does not only have drawbacks

    source
• PrimeApe@discuss.tchncs.de ⁨1⁩ ⁨year⁩ ago

  What’s the current tech stack and why do you think they chose it?

  I can continue a convo if you give me a bit more

  source

  • starman@programming.dev ⁨1⁩ ⁨year⁩ ago

    Rust backend and Inferno frontend AFAIK

    source

    • cynber@lemmy.ca ⁨1⁩ ⁨year⁩ ago

      I don’t have as much experience working with the stack, but from what I’ve read it seems like Rust is a pretty solid choice for the backend. It also seems like a lot of the upgrades people want are for the front end, so that’s what would benefit the most from being simpler.

      Typescript makes sense, and a handful of frameworks have typescript support. What are the benefits of using Inferno over something like Vue/Nuxt or plain React?

      source
• nyan@lemmy.cafe ⁨1⁩ ⁨year⁩ ago

  The choice of stack would matter a lot less if the documentation were better. Last I checked, having to figure out the details of message semantics from scratch made writing better frontends or alternative server implementations in other languages ten times more difficult than it needs to be.

  source
• lilShalom@lemmy.basedcount.com ⁨1⁩ ⁨year⁩ ago

  I wish it was easier to install.

  source
• sashanoraa@lemmy.blahaj.zone ⁨1⁩ ⁨year⁩ ago

  I quite like Rust so I’m biased. But I understand it’s not always the best choice.

  source
• Crackhappy@lemmy.world ⁨1⁩ ⁨year⁩ ago

  Duh… Definitely LAMP

  source
• kakes@sh.itjust.works ⁨1⁩ ⁨year⁩ ago

  Flask backend Blazor frontend

  source

  • Kuinox@lemmy.world ⁨1⁩ ⁨year⁩ ago

    I read flash and was horrified a second.

    source

    • kakes@sh.itjust.works ⁨1⁩ ⁨year⁩ ago

      Can actionscript be used for a database?

      source

      • -> View More Comments
  • starman@programming.dev ⁨1⁩ ⁨year⁩ ago

    Why did you chose Blazor and then Flask instead of .NET for backend? I’m just curious.

    source

    • kakes@sh.itjust.works ⁨1⁩ ⁨year⁩ ago

      Ngl I was going for worst possible stack. Not that either one is bad on its own, but like you said, I don’t think anyone in their right mind would choose this combo.

      source
• ArtemZ@nowoke.social ⁨1⁩ ⁨year⁩ ago

  I’d probably go with a different database engine. Postgres is not scaling really well and poorly suitable to throughput intensive applications like tracking activities, upvotes etc.

  source

  • ICastFist@programming.dev ⁨1⁩ ⁨year⁩ ago

    Which one would you pick? Cockroach?

    source

    • ArtemZ@nowoke.social ⁨1⁩ ⁨year⁩ ago

      Probably a big data oriented NoSQL database like ScyllaDB. It provides eventual consistency with fast and efficient reads and writes, but high availability, which seems like a perfect fit for the case. CockroachDB favors consistency in place of availability which doesn’t seem to be really a priority for Lemmy instances. You would rather have some upvotes, posts and comments missing sometimes than not being able to load the rest of the data.

      source
• rikudou@lemmings.world ⁨1⁩ ⁨year⁩ ago

  I’d probably go with Symfony for the backend and Angular for the frontend.

  source
• tomba@lemmy.cat ⁨1⁩ ⁨year⁩ ago

  Good old PHP and HTML+vanilla JS

  source
• ICastFist@programming.dev ⁨1⁩ ⁨year⁩ ago

  I’d go with Elixir + Phoenix for the backend. Though that would also mean not many people would manage to contribute, as it’s not a very widely known or used language. It is very resource efficient, tho, so it should scale upwards very easily

  source
• somegeek@programming.dev ⁨1⁩ ⁨year⁩ ago

  It has the perfect stack

  source