Lemmy is an open-source, federated link aggregator and discussion platform similar to Reddit, Lobste.rs, or Hacker News. The software stack used in Lemmy includes Rust with Actix and Diesel for the backend, and TypeScript with Inferno for the frontend.
The developers chose Rust for its performance, safety, and concurrency features, which help in building a reliable and efficient backend. Actix is a popular Rust web framework that provides a lightweight and fast foundation for the server-side application. Diesel is a Rust ORM (Object-Relational Mapping) and query builder that simplifies database interactions. On the frontend, TypeScript offers better type safety and tooling compared to plain JavaScript, while Inferno is a fast and lightweight React-like library for building user interfaces. These technologies were chosen to create a performant, reliable, and easily deployable platform.
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 to it. So I was curious to know what other people would have used.
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.
Edit: I’m not one to complain about imaginary internet downvotes, but can we be better than reddit please? Downvote is not a disagree button. The question was what would I have chosen, not what the most popular web framework is this year. It’s cool if you would have chosen something else. This whole thread has become “what framework does everyone like the most currently?”
I know Rails too, and have used it longer than any framework, but I’ll never recommend it to anyone due to my personal trauma and a very small community, which seems to get smaller every day.
Rails was the “career” killer for me when there was no job shortage, and we were graduating at the middle of 2022.
Most of the tutorials on Rails are pretty outdated, and ironically, most people use Rails as the backend API, and not with the templating engine, and the API guide is really lacking.
There’s too much radical changes. First from sprockets to webpacker and then import-maps and esbuild with optional propshaft. And then the in-built Hotwire is so hard to grasp. But I like esbuild + Propshaft. I think they are good changes, but radical enough to do the process of unlearning.
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.
I would blame it on me for not checking the market tech stack. Folks who learnt React, ExpressJS and Next.js were rewarded. The rest of them, not so much. At least in my area.
Now that there’s a recession, I am screwed no matter what tech stack I learn. While the rest of my colleagues secured jobs, Rails got me nowhere. I know that none of the reasons I’ve mentioned are rational enough to avoid Rails, but I am not using this thing any more. I am in the worst place right now, but seeing the name of this framework just brings in flashbacks and ruins my mood even more.
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.
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.
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.
Yes, you’re right about that. Personally, I prefer esbuild with Propshaft over importmaps (as I try to avoid CDNs personally), as it has improved a lot, especially if we are talking about assets management, but again, I think if I were to make a project in the future, I would create a monorepo with Rails API-only and Svelte, because of how hard Hotwire is to understand. Especially Stimulus.
Webpacker in Rails was a nightmare to configure and the stuff before also not the best to play around with. Setting up Bootstrap and PopplerJS was so hard back them, I can’t imaging how hard the Tailwind setup can be.
Currently, I’ve made the switch to React + Express and SvelteKit. React + Express became it is quite popular in the market. SvelteKit because I love this framework. But I would love to choose Golang as a back-end. Maybe in the coming future.
And about open-source licenses, valid point. I should have been careful there.
Yeah I’m not sold on Hotwire either. I started a new Rails project last year with Rails 7 and removed all of the Turbo/Hotwire stuff and did it all with import-maps and vanilla JS. Import-maps don’t require a third party CDN though. I absolutely love that I can use them to write ES6 JS and have it served directly to the frontend without any Webpack/ESbuild compilation step in between. After a decade of working with the nightmare that was Webpack & Webpacker in Rails I’m totally with you on how that whole asset management system needed a big overhaul and I think with importmaps or esbuild we might finally have something tolerable.
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.
Interestingly, the only internship I was able to secure was a Rails internship role. This was around October 2022 till Jan 2023. And most of my bad experience also stems from the same.
I had to use Rails 5 with Coffee script. There was literally no development or test data, all the stuff happened on production. I accidentally nuked the production, became the default rails option to reset development database also affected the production. There was no proper issue tracking system. No proper commit convention. The code was untidy and didn’t make any sense. I didn’t complete the internships and quit midway. And since then, I’ve been jobless.
I know Rails 7 has improved a lot, but I think I should have started with a micro-framework backend first, instead of touching a batteries-included full-stack framework. Using ExpressJS definitely helped me to understanding parts of the backend, especially middlewares.
I feel your pain. Before landing where I am now I was tasked with bringing a Rails 3.22 (edit: it actually took me about a month before I knew the true version because it was a forked 3.22 with a ton of 4 back ported into the fork) app up to Rails 7.
There seems to be a lot of bad design decisions in the earlier versions of Rails — for the most part I’m referring to the users of Rails (developers) rather than developers of Rails itself.
Ruby’s downfall is that unless you’re an experienced developer it’s pretty easy to get by with poor design decisions. I’m literally explaining myself: I’m self-taught but I didn’t start coding professionally until about 4-5 years ago. I run a small business on the side that’s powered by my very own old code without tests, huge models, and cringeworthy blocks of code.
What I think you’ll find is that it’s mostly senior positions open. A lot of companies wrote something quick back when Rails was the hot new tech, let it go for a decade and then started screaming “help!” at the job market when things started breaking.
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.
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. The only thing I’d ever use rails for is a small scale project, like a small business website/webstore. IMO, it’s not suitable for websites that need to serve large volumes of data that doesn’t cache well at the page level.
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.
Without benchmarks, this is a subjective statement. Ruby 3 is quite speedy now, at least I find it to be. Performance is even better with YJIT enabled in Ruby 3.2. 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.
I’m not entirely sure what you mean by this, but Ruby introduced fibers a while ago.
Not true anymore. Ruby has had a compacting GC for a while now. This was a difficult problem to solve because of Ruby’s support for native extensions. Otherwise it would have been done much sooner.
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.
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.
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.
Drop in gem that will automatically solve 99% of N+1 issues: https://github.com/clio/jit_preloader
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. Not a true expert per se, but knowledgeable enough to get stuff done, which at the end of the day is what you need to do. 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.
Am I saying that Ruby/Rails is perfect and there’s no problems? Of course not. There’s no such thing as a perfect language or framework. But I also think that Ruby is unfairly demonized because of lack of familiarity and it being less used than JS and Python frameworks. And oh boy do I have complaints about JS frameworks. But I wouldn’t go so far as to call any of them “terrible.” Maybe it’s not my/your cup of tea and that’s okay.
I could be mistaken, but I believe these sites are normally “using rails” (as in they shell out to other languages, Go has become common, for performance critical end points or portions of those end points that need to work a bit harder). I also suspect they’ve got some pretty heavy modifications.
I haven’t worked with Ruby since… 2.5(?). That’s very fair about the JIT improvements.
The Ruby language itself has fibers, but last I knew Rails was not making use of fibers for ActiveRecord. The problem is effectively you’re in an interpreted language (bad enough) without real parallelism (worse). So, when any IO occurs one of your non-parallel threads is blocked. Ruby jumps around to process the different threads, but this creates a context switching problem and you lose a lot of performance to the preemptive multitasking’s context switches (and resources are hard locked up by the IO).
With a coroutines or fibers based approach (cooperative multitasking) you don’t need multiple threads, the “callbacks” just fire into the appropriate place when IO is fulfilled (what NodeJS is famous for). You can get way better throughput and it becomes trivial to execute queries that aren’t co-dependent in parallel (so your page that depends on 10 different queries gets resolved much faster, and your app can work on other pages while that data is being resolved in the background).
It’s not a silver bullet, you can run into issues if you have CPU bound tasks on the event loop thread (and thus create latency issues as things just aren’t getting finished). However, in a well designed web app that shouldn’t happen anyways (this stuff should be in background job queues, or at the very least running in separate threads – in Ruby that likely means processes unless the threading has significantly improved).
That’s good to hear.
RBS is definitely newer (I stopped working with Ruby around 2018). Looks like Sobet was just getting started. Also good to hear.
I’ve changed my stance over the years from “it’s a matter of preference” to “it’s objectively bad.” The lack of any type structure leads to a significantly larger requirement in unit testing. Unit testing can be good, don’t get me wrong, but in our org it had gotten to the point we were writing unit tests that effectively tested “did the code change” … and I don’t think that’s a good workflow. You’re lacking a compiler to do type checks for you (when you refactor something) so you have to write all the code to catch things the type system would’ve taken care of for you.
Put another way, I don’t consider a unit test for a function as trivial as:
return a.y + 1To be superior to the type system telling me
yno longer exists. However, ifyno longer exist, I still want to know before a customer bumps into the inevitable crash.The problem you run into here is a lack of mature libraries to leverage if you want to do anything non-trivial. e.g., our application needed to read from spreadsheets. The Ruby libraries either A) didn’t have support for common formats like
xlsor B) would load the entire spread sheet into memory represented as Ruby objects (you can predict how well that performed :) ).Without potentially breaking a NDA, that made the effort to get efficient spread sheet processing much more challenging than it would’ve been if we’d picked a language with more reach; this is just the main example I think of, there were others.
I think we eventually started using something akin to that. However, I’m a big advocate for making the wrong thing look wrong/complicated, and Rails very often makes the wrong thing look simple. Note that gems like this don’t really solve the problem they just inform you when you’ve made the mistake, or alternatively forcing your app into hammering your database even in situations when it doesn’t need to (which can drive you back to my earlier points about the lack of cooperative mulitasking to deal with the IO bottlenecks).
I agree, but there is something to be said for hiring people that are extremely knowledgeable in the framework to help highlight solutions (like those you’ve mentioned here) vs “you’re a great C++ dev, now go do Ruby!” It’s not a deal breaker, but when you hire folks like that the time to get them up to speed is going to be far higher, and they’re going to make mistakes that in a sense “aren’t at their experience level” (particularly with the former point about making the wrong thing look wrong considered).
I’ll concede my initial reply/stance was a bit bold, and you’ve definitely highlighted serious improvements in the ecosystem I’ve either overlooked or forgotten about… Perhaps I should’ve said was terrible; I’m not rooting for Ruby to fail, but I did have a bad experience.
I can’t speak to what they’re doing internally, but I would agree this is a safe assumption. I think the point though is that Rails, with some help of external services depending on use case, can certainly be scaled out to a level that is far above the average web service making it more than capable of handling 95% of use cases you could throw at it. In the case of Shopify, they’ve traditionally been great about contributing optimizations back to Rails so their performance optimizations are shared with the larger ecosystem (and has the benefit of keeping them closer to upstream).
To your point, Ruby recently introduced Ractors which are true parallelism. They’re new enough that their use isn’t widespread yet, but I’ve played around with them and it’s definitely neat to have real parallelism in Ruby now. And for web services, this would depend too on the web server. For example, using Puma or Unicorn will have multiple worker processes so there is some parallelism between requests regardless.
Yeah, I get that. For what it’s worth, I really can’t think of a situation where there hasn’t been some library written in Ruby for something that I needed shy of extremely esoteric stuff that I likely would have needed to write myself if working in another language anyway. But that’s going to be highly dependent on a case-by-case basis. For what it’s worth, I make it a point to use as few third-party libraries as I can unless they’re highly popular. It’s a problem in all languages that random person’s pet project library, while highly useful, becomes abandonware far too often.
You might be referring to the Bullet gem which is just a notification that there’s an N+1 and where to find it so it may be fixed. However, the JIT Preloader gem actually does automatically solve the problem of N+1s in nearly all cases (see the README for details if you’re curious). It’s the closest to a silver bullet solution for the N+1 problem as I’ve seen and I now give almost zero thought to N+1s anymore. I know the devs were wanting to get it merged into Rails to solve this problem for everyone, but I don’t know what happened to that effort.
Right, I wouldn’t portend that anyone can make an easy switch from, say, embedded systems to web development in a few weeks or even a few months. I meant more like if you’re competent web developer the core concepts of building web backends/frontends don’t vary all that much between frameworks. At the end of the day, the underlying concepts deal with HTTP and HTML/JS/CSS so if you have a solid understanding of the base concepts and system design for the backend it shouldn’t be much trouble to switch the framework sitting on top of those, especially if you have a team around you that is effective at code reviews, answering questions, and generally investing in new employees. Like you said, switching from something totally unrelated is a different situation though.
Thanks for a thoughtful reply, by the way. :) I really shy away from getting into pointless internet fanboy debates over which tool/language/framework is “best” but always enjoy when there’s thought out reasoning behind points.
and at some point in the future, the possibility of upgrading from Ruby to Crystal …