I don't have any experience in Rails, but similar experience with Django. I am running several apps on my own, while still working elsewhere full-time.
The largest one has around 250 views, of maybe 80 are just basic admin views. It is basically comparable to an ERP of a medium-side company with various levels of permissions etc. I was able to get most of the functionality into production in just one month -- I was not working full-time at that time. I have estimated it with some friends, and such an ERP in the corporate world would normally take a team two years to do -- one to spec and another to implement.
It has 1-2M monthly page views depending on the season, and the highest hitting pages are read-only and heavily cached, so the server load is minimal. I am further increasing the performance by making those pages static HTML using django-distill and using Cloudflare to cache/serve them.
The key thing is to keep things as simple as possible. I avoid REST/heavy frontend frameworks whenever possible. For most views for most apps, normal HTML form request-response user interface based on Bootstrap is perfectly fine.
I started by sprinkling Javascript when it was really needed, for example client side sorting so I can avoid server load. Now I use AlpineJS/HTMX for the interactivity. It has been great, although much slower to implement.
I'm not a huge fan of Ruby, but even if you admit that Rails is superior to Django, it would be a hard sell to invest in Ruby ecosystem instead of Python
I'm doing something similar to OP with Django right now
I worked with Rails and Phoenix in their early days and got plenty of value from each. If you're building a traditional web 2 app, look no further...similar to choosing Postgres, start there until you have really good reason to venture off.
Without taking away anything from these frameworks and as someone that spent over 10 years building app frameworks, sometimes it's not what I want.
I'm using Clojure for my current problem space which would stymy me if I tried to use Rails or Phoenix. I spent the past 4 months doing product/domain "shaping". There are no web pages yet..mostly pure server side domain and API calls for data gathering. After this exploration I now have several working subsystems and have figured out the pathway to the mvp which will come together quickly. As a bonus I have a working domain core to leverage for steps after the mvp.
It’s funny you mention clojure, cause I when I saw “one-person framework” I instantly thought of Biff.
I haven’t used Biff (clojure web framework, does not sound comparable to rails), but there’s a great episode of The Repl with the dev who created it. It’s one of those interviews that reminds you how fun and creative programming can be
As an American, I've never seen that spelling, and I can't find much evidence that it's an accepted spelling. I'm curious how you came to that conclusion.
"Stymy" doesn't appear in Merriam-Webster [0] nor the OED [1]. Wiktionary [2] and Dictionary.com [3] do list it as "variant" or "alternative" spellings, but with no indication that it's an American spelling.
Reading through the list of Google web search results, collinsdictionary.com said it was American English. I should have put my faith in chatgpt instead of google search.
I would argue that framework isn't the winning component, the people are. A lot of people can say similar things for framework <<X>> and they'd be right given their own experience but I think they give themseleves too little credit. I've written my own frameworks for smaller projects because I didn't want the needless learning curve / cruft of a generalized framework and I can tell you they saved me so much time / effort / cost over the long term and they were tuned to my development style. All built with python and some off-the-shelf libraries. I'm not saying there's no place for generalized frameworks. They do help streamline development efforts and set a standardized model for building out your app/service which would be great with a team of people all tuned in to a specific framework but I would argue that in a single developer environment it doesn't matter much what you use, so long as you have fun with it. Productivity analyses are at best personal opinions in a forum like this.
I'm currently building out an app using AdonisJS. Its billed as a Rails like experience but in node. https://adonisjs.com/
I did a comparison between Rails, Adonis and Fiber (a Go "framework") before settling on Adonis (mostly due to node ecosystem and type safety).
It's been excellent so far, and the creator has an excellent series of tutorial videos that can get you up to speed quickly https://www.youtube.com/watch?app=desktop&v=jf5hHU0KT3Q. The documentation is also good. LLMs can get tripped up by older versions which you need to look out for.
I found the lack of 1st party auth system annoying. Phoenix, for example gives me a nice starting point (even magic links soon). Adonis for all its features, turns me to what I hate. The JS auth implementations.
Yeah, dealing with auth can be painful. The adonis provided auth and bouncer do a decent job of abstracting some of that away, but like most js implementations, it's got rough edges (the docs and vids really help).
I'm not familiar with Elixir/Phoenix, but from reading other recommendations in this thread and after having a quick look, I need to take a closer look :-)
Is there a 1st party auth package? I can't remember any - They were guiding you to the adoniscasts videos, which some are paid. Very hard to get traction like this.
For anyone who's ducked out of Rails World over the last decade (or two), I devoted my final conference talk last year to the topic of One-Person Framework with a real-world case study of how Rails 7+ specifically helps developers build ambitious apps, even as a solo developer. https://justin.searls.co/tubes/2024-11-09-11h03m00s/
Rails is, if I'm being honest, better than Django in a lot of ways. Hotwire, the new SOLID cache/queue, turbo-native, etc.. But I still prefer the overall python ecosystem.
I'm currently building an application to launch it soonish. I'm using Rails and doing everything myself (save for the design of the logo, and some input from a friend on UX).
What's more is that I'm building mobile applications using Hotwire Native. I'm a solo developer building 2 mobile apps(iOS and Android), supported by a fully functional web application and done with vanilla Rails with Hotwire Native.
I'm surprised how well Rails ecosystem is suited to do everything nowadays.
The way I describe language types to non-coders inquiring about language selection for a given project is simply “scale matters”… dynamic types provide flexibility at small scale, but can very easily result in chaos at a large scale. Conversely, the structure of static types can feel onerous and restrictive at small scale, but provide robustness and structure at large scale.
If you mean codebase complexity and team size... then yes... types is more helpful with that. But in a small team with a small codebase you don't need types to do really well. I find types helped a lot when multiple teams were responsible for different domain spaces inside different components of a Rails app. I never saw the same advantage in codebases that are much smaller with fewer people.
I see what you mean but I have never found it to be an issue even in large codebases. Sorbet and RBS have been problematic. Lots of development slows down with these solutions. I wished it had something baked into the language as well but I'm happy without... just following conventions alone has worked really well for me.
Yeah I just can't go back. How fast you can confidently refactor and the improved tooling is the biggest thing for me
You can do fine without them - Basecamp proved that. There's a good reason basically every other Rails company eventually moved to static typing though
I started my app using Rails and Hotwire/Stimulus and honestly finding myself way more productive than I did with more JS heavy options. Everything just works so nicely together in the Rails world.
I don't know if the framework really matters that much?
Just choose anything popular and there should be plenty of help available.
I've been using Laravel for about 11 years now. I hate it, but it keeps on trucking along so I've resisted the urge to do a complete rewrite. I don't think anything is particularly slow to develop.
It's the business side of things that's the hard part.
It matters a lot. I attribute my success at running a one-man business to Laravel (inspired by Rails). Having a batteries-included framework designed to support high-level business goals reduces so much cognitive load and the amount of code you need to write. Previously I had 10+ years of experience writing apps in basic Python frameworks like Flask but I would need to spend far more time writing code to implement basic features. Another thing that drastically reduces complexity is having the backend and frontend in a single codebase. In Rails that is achieved with Turbolinks and in Laravel it’s done with Livewire. It reduces code complexity by a factor of 2x at least (in practice it’s like 10x simpler compounded over years of maintenance).
I have heard that for years and I just don't get it. Magic abounds. The test assertions and testing libraries are whole DSLs that require a separate/additional learning process with inconsistent chaining with inconsistent return types. Being able to overwrite anything in the language gives rise to things like unicode whitespace being misinterpreted as an undefined function. You can define methods by combining method names leading to wholly undiscoverable methods because "my_func_that_is_cool" is actually defined over multiple files, combining my_func and that_is_cool; saw this a lot in our chef cookbooks. Ruby requires mountains of tests (thus the DSLs). Knowing ruby and knowing rails and knowing how to test are different things.
I find ruby (and rails) to bring the opposite of joy. I find myself frustrated. On the opposite end of magic is Go. I love Go. Tests are just code; no magic needed, not even mocks. Methods behave and usage is consistent. Code is navigable. Types make everything more explicit and easy to follow and more maintainable.
I assert Go leads to org happiness, letting teams work together productively.
Is there any other framework which can claim that it compares well to Ruby on Rails speed of development? I.e. conventions over configurations? Asking as I don’t want to learn ruby
Elixir + Phoenix is amazing. It's one self-contained stack. Just Elixir processes (and Postgres) which takes care of everything other ecosystems farm out to extra services. Background jobs, real-time channels, and even hot-code deployments run natively within the same BEAM runtime.
Working with this with a small team with one simple stack is a breath of fresh air in today's world.
I’ve always heard awesome things about elixir/beam but I only have so much love in my heart for languages without good static types. Right now that love goes to clojure!
I’ve been hearing some buzz about static types landing in elixir, and it’s definitely piquing my interest. This comment of yours has fully sold me though!
This was my first impression too but I wasn't sure it covered the OPs convention over configuration stipulation.
Elixir/Phoenix is far and away my favorite framework to build with, but it does leave some things up to the user in a way that Rails doesn't, eg: there is no automatic `class name -> db table` mapping, or automatically inferring what partial or form names to use by a variables name.
In my mind, this is not a downside and there are still idiomatic ways to write Phoenix code, but just to outline some philosophical differences I guess. In the end I much prefer it because everything's a bit more explicit and flexible when I want it.
I think Phoenix also expects read documentation around OTP if you want to really achieve high leverage. This is worth it, and you can sort of drip feed yourself by starting with Phoenix, recognising that Phoenix primitives [sic] are actually Elixir primitives are actually just OTP primitives and you end up with some pretty good examples of how OTP works in a system you're already familiar with.
I've been slowly / occasionally dipping my feet into Elixir / Phoenix dev over the past year or two, building an app idea that's been floating around in my head for a while. It's a bit of a steep learning curve for me, coming mainly from Python land (Django / Flask / FastAPI); I understand that it's designed to be a gentler learning curve for those coming from Ruby / Rails land. Phoenix is also a lot less mature / less feature-complete / less thoroughly-documented (than I had hoped, and) than Django / Rails (many of my Phoenix questions I've only found answers for in the forums, rather than in the official docs). Nevertheless, I agree, BEAM / Elixir / Phoenix is awesome, I'm hoping to get into it more in future.
I had the opposite experience coming from Django/Flask to Elixir/Phoenix. I found it very comfortable and that there were many similar patterns at the framework level. Now, LiveView is a bit of a different story but basic Phoenix routing and views seem quite similar to Django routing and views. Ecto's model schemas have a decent amount of overlap with Django's model objects.
Was it the LiveView stuff that felt foreign? I'd agree there's a learning curve there as someone coming from Django.
Laravel. Massive batteries included ecosystem and the mental model for PHP programming fits the web so freaking good. Rails 8 tried to catch up by beginning to shape the first party queue story, while Laravel has been there for a decade and the tools have been vetted at scale.
For a skilled developer who knows any of the major MVC web frameworks, they’re all really productive, just in slightly different ways.
One big up for Laravel and also Symfony, the other big PHP framework!
And now with InertiaJS, there are no more API endpoints necessary for any UI stuff.
The data just gets prepared in the controller in PHP and gets directly loaded as JSON into the React/Vue/Svelte frontend pages, thats it!
In each of the dynamic frameworks I have worked in, besides lacking types, the biggest problem is domain separation.
In 4 out of six large, dynamic code bases I have worked in, everything becomes spaghetti. This joins with that which n+1s with yadda yadda. You end up with dependencies that prevent billing options because you can't separate the billing structure from the user model from the product table. Queries start joining and joining and you get monstrosities of queries. The beefy postgres db gets bogged down at less than 2k rps. Everything gets slower. Then the org spends millions and millions on domain separation and breaking teams away from another. Builds get slower. Competing styles of decomposition litter the codebase. Changes take days to release. It takes Herculean effort and heroics to fix a dynamic code bases that grows, eating at growth when it should be compounding.
"But it let us get here, where we can afford to do those changes." Maybe. It is the road less taken's point - you can sell yourself that the dynamic code bases allowed for the success. But that doesn't say the alternative wouldn't work.
I’ve been asking this question for a while since I love Rails but I don’t like Ruby that much.
I think only Django comes close, although I haven’t tried it, but I dislike Python much more than Ruby.
There are always attempts in every language to replicate the convention over configuration and batteries included approach of Rails, but they all lose steam pretty quickly.
I just don’t think there is an alternative to Rails. It’s a giant project that is actively developed for over 2 decades now.
I used to code ruby. Now in python land and am using flask. Theres conventions but no scaffolding. Ai code tools make the scaffolding feel redundant anyway.
Coming from Ruby, Flask is much more of a Sinatra than a Rails. It’s very batteries-not-included. You basically just get routing out of the box. DB ORM, forms, auth, mail, background task, etc. are all DIY. That said, there are high quality packages to do all of those things within the ecosystem and I really like that I don’t feel like I have so much unused bloat in the framework when I’m making a small service.
In Rust we have loco[1], that aims to be a Rails for Rust. I personally have never built anything serious with it, but all the toys projects were pretty enjoyable.
As someone who likes Rust, has one project (web based) in production in Rust, and considering starting another one, I'd be glad to learn from the experience of other people.
I have several apps in production.
I employ sqlx, axum, async_graphql, React frontend.
So far I don't know any better way of doing it and I have tried all the classic ways like PHP, Django etc. This is way superior. The only downside is that I am the only one who can touch the backend, but I guess if some of the projects grows enough, there will be enough incentives to find another Rust programmer besides me.
Yes, this mirrors my experience as well. It's just every time I see someone who "quits" Rust in order to go back to Ruby/PHP/Python, I'm interested to know what part they were struggling with.
If you value types more than completeness, Krop is a framework for Scala: https://www.creativescala.org/krop/ It's only suitable for very brave developers at this point in time, as it is nowhere near to feature complete.
Meteor.js offers pretty good iteration speeds and a fairly complete toolbox for the JS world. Fully featured accounts system, RPCs, client/server reactivity, etc.
It's niche, but check out https://www.boxlang.io/ and https://www.lucee.org/ on the JVM. They're rock solid runtimes. I single handedly manage multiple production applications going on 10+ years. They essentially never break, never need major maintenance. Backwards compatibility is great. The runtimes are very batteries included in terms of backend web development.
I’m curious if .NET can compare here, though I have limited experience with rails or ASP.NET both seem to give you a lot to work with. Though the overlap of rails devs with .NET devs seems minimal.
I learned to code professionally in Ruby but wrote C# .Net for almost 10 years. I've probably forgotten more about .Net than I ever learned about Ruby at this point so take what I say with a grain of salt.
.Net has tons of configuration and boilerplate so I can't say that it's exactly the same in that sense, but the more meta theme is that just as there is a Rails way to do things, there is a Microsoft way to do things. Unlike Java where you're relying on lots of third party packages that while well maintained, aren't owned by the same company that does the language, framework, ORM, database, cloud provider, IDE and so on. Having a solid well documented default option that will work for 99% of use cases takes a lot of the load of decision making off your shoulders and also means you'll have plenty of solid documentation and examples you can follow. I've been in JVM land for the past couple years and it just can't compare.
I know Java people will come fight with me after this but I just don't think they know any better.
I don't want to fight you, because I don't know .Net well enough to have an opinion.
But I just want to say that I have the same feel when I develop using Spring Boot. I am extremely productive and seldom have to pull dependencies outside Spring for 80% of what I make.
I still don't get why .NET barely ever gets mentioned in these threads. Even new or niche frameworks like Phoenix, loco.rs and others get mentioned, but almost never .NET. It's as "convention over configuration" as it gets.
Platform support and open-sourcedness. The Phoenix 1.0 release predates the first open-source and Linux-supported .NET release by a year, for example. .NET is just now starting to shake off its association as a closed-source, Windows-only thing.
People aren't just going to jump onto something recently open-sourced by a company that popularized the phrase "embrace, extend, extinguish". For the last decade, they've had to earn people's goodwill, while with a project like Rails, there is no "we used to be closed source but now we're not, use our thing!" to overcome. So in the 20 years since Rails has been released, it has only ever needed to demonstrate its usefulness.
Now that a decade has past, that negative association is starting to wash away a little.
Django is more or less Python's equivalent of Rails. Its admin panel is nice, especially for a solo developer trying to manage something they built in a weekend.
Filament, and it’s fucking awesome. I think it’s way better than Django’s admin panel, and I’ve used it to build out both my Laravel admin panel and basically all of the UI for users.
I have heard Laravel is shockingly complete and most others will pale in comparison to in terms of out of the box speed to first feature and the full CI/CD setup for most any kind of product.
Speed of iteration varies within a single projects entire lifetime.
My speed of iteration in dynamically typed languages is great at first, but after running in production for 8 years, coded by a team that never wrote the original, dynamic typing hurts iteration speed.
If you judge iteration speed by how fast you get to feature #3, I've got a ton of bash programs that will beat any serious language product you have on that metric.
Speed of iteration is for speed of feedback and insight from the business/market into the product.
That can be a mix of how you see it, how the business works and how the code does anything.
It is important to understand I’m not referring to dynamically vs statically typed languages or not. It’s a distraction. Code runs fast on pretty much anything these days, and dynamically typed languages have pre-compilers.
These are sometimes matters of personal experience, interpretation, preference and opinion masquerading as facts.
Most languages have to abstract from to the web using a framework and that additional interpretation is where a lot is lost.
Featuritis is the disease, solving problems solely based on customer input (who are strangers) is important. Problems are rarely a single feature, but a sequence or group of them.
The irony of bash scripts is they can be some of the most durable and well lasting parts of a project while everything around it might change and evolve quicker. So if there’s some bash scripts being called by a language in the beginning.. so what.
My original point about Laravel is I have not seen as tightly integrated of any ecosystem to ship solutions and product where so much time is not lost in the product side of it (accounts, billing, migrations, etc). While I’m relatively new to it, at the very least it’s a worth comparison to show the holes in others.
Django is the closest I can think of. Many unicorns built on Django.
Both Rails and Django are horribly slow though, so once you get to some critical scale you gotta start doing some real weird stuff like Instagram did with turning off Python's GC [1], etc.
Regarding the slowness, I think it's super important when working with slow stuff like Django to have good SLOs in your head.
"Home page should load under 2 seconds at P95", "reports should load under 10 seconds at P99", "this background task should take under 30 seconds at P99".
Having these targets (and, frankly, remembering in the B2B space is that the status quo is _so slow_) can let you set performance objectives without chasing milliseconds that you don't need to.
Django has a lot of intrinsic slowness to it, "easy" DB access patterns often lead to heavy messes, but if at the end of the day most customers are getting served under some benchmark you can reap the advantages of the tooling without sweating perf too much.
And when you set these SLOs, you can then push for even tighter ones as you figure out your problem space!
In the B2B space companies get away with _so much_ sluggish behavior, if you're better than the median that's already improving things.
My previous company had a sizeable Django monolith and did e-commerce stuff which is fairly latency sensitive. Used well, Django was perfectly capable of hitting 150ms per page which was fine for us. Some optimised pages were under 100ms.
Things we did: careful about N+1 queries, caching where obvious, API calls/emails/etc running in background queues.
Things we didn’t do: use a fast templating language (we used Django’s built in one and it was often our bottleneck), removing all database queries (we just had Postgres <2ms latency away), renormalising data (we were highly relational for most things).
Django is perfectly performant enough for almost all use cases, and insanely fast to develop with.
Yeah you can make Django go really fast, especially when you have pages that well scope what data they are pulling from (though you seem to know it better than me).
I think B2B SaaS, for "normal" teams (read: people not that adept at building scalable systems), when not careful, tend to make omnipages where about 20 different things are happening. Even just navigating to a page ends up triggering random side effects (driven by various needs).
There you can easily find yourself in a performance pit that you have to dig yourself out of (often redesigning features in the process to remove some stuff).
I just find that setting fairly easy performance goals can help to make perf seem more tractable.
I use Django with Vue CDN for the MVP. The framework is similar to RoR. The key is not about the framework IMO, but whether you pick up a good track. If the demand is great, you can feel the pull from the market. Otherwise, whatever framework can't save you from failure.
Developer experience and the choice to keep complexity low make a much bigger difference. The things Rails solves for you are, these days, solved problems in all mature languages that are used in web development
(coming from close to a decade of Rails experience on my end)
Having worked as a basically one person Rails shop I think one of the things that makes a big difference on productivity is whether you can say no to the big react front end or not. (And I say that having come to like GQL: It's still like 5x the workload to have a react app + Rails back end.)
> Sticking with a well-structured monolith was one of my best decisions.
I can't emphasize this enough. Did the same with a monolithic PHP application. David Heinemeier Hanson used the term 'majestic monolith' and it really feels like that, working on some cathedral in code.
Congrats on your good choices and results. A programming language that you like is important, but I think you should give your own decision making some more credit.
I think you're not giving yourself enough credits and you're giving Rails too much.
I know a developer who followed a similar approach in PHP.
A relative of mine is running his company as a single dev in node.js + react.
My company runs on Python.
The key skill is being a good generalist willing and capable to do all the roles you need.
Every tech stack can be automated for most small business needs, so that you can reduce the time spent on it.
I agree. Nothing beats using a well known framework for speed.
I think we also need to consider how much experience one has with a language. Most can pickup a new language relatively quickly, but it's not the same as having real experience with it.
At work, someone just started a new micro service written in Rust because they were familiar with Rust and thought they would be able to do something "fast". They spent at least half the time struggling with even basic dependencies, how to deploy it, monitor it and make it deployable. If this was a startup, they would have burned a significant amount of time that could have been spent on PMF
Ruby is plenty fast these days (people usually think Ruby didn't get faster but it did). And if we figure out how to switch to async/fibers with let's say Falcon, we are in a good place :)
Ruby isn't standing still in terms of performance either. YJIT is getting better all the time and ZJIT is on the horizon too.
For concurrency, async fibres are brilliant but not the only game in town.
Using good old processes works really well in Pitchfork or alternatively JRuby and TruffleRuby both have true non-blocking parallelism right now using Threads.
If anything TruffleRuby shows that there is nothing inherient in the Ruby language that means it cannot catch up in performance terms.
Indeed. Runtime is typically a lot faster than Rails. Response times in dev mode are <1ms which is fun to see coming from Rails :)
My personal dev speed however is a little slower in Phoenix than Rails. And I've been using Rails for almost 20 years and Elixir for 10.
There are categories of problems that are much easier in Elixir (High concurrency, low latency, etc) and for those I would always pick Elixir. If you're planning "just" a crud like web application, Ruby will probably get you to product-market-fit faster. There are (well maintained) gems for almost everything.
Let’s be clear - the success is not because of Ruby on Rails.
You could build the same thing with nodes or python or golang or whatever.
There’s nothing special about rails, except that the developers speak like it’s special.
There’s nothing that can be quantified in any tangible way to indicate it’s actually better in any way. Rails has enthusiastic words, but it’s not actually better.
I don't have any experience in Rails, but similar experience with Django. I am running several apps on my own, while still working elsewhere full-time.
The largest one has around 250 views, of maybe 80 are just basic admin views. It is basically comparable to an ERP of a medium-side company with various levels of permissions etc. I was able to get most of the functionality into production in just one month -- I was not working full-time at that time. I have estimated it with some friends, and such an ERP in the corporate world would normally take a team two years to do -- one to spec and another to implement.
It has 1-2M monthly page views depending on the season, and the highest hitting pages are read-only and heavily cached, so the server load is minimal. I am further increasing the performance by making those pages static HTML using django-distill and using Cloudflare to cache/serve them.
The key thing is to keep things as simple as possible. I avoid REST/heavy frontend frameworks whenever possible. For most views for most apps, normal HTML form request-response user interface based on Bootstrap is perfectly fine.
I started by sprinkling Javascript when it was really needed, for example client side sorting so I can avoid server load. Now I use AlpineJS/HTMX for the interactivity. It has been great, although much slower to implement.
I'm not a huge fan of Ruby, but even if you admit that Rails is superior to Django, it would be a hard sell to invest in Ruby ecosystem instead of Python
I'm doing something similar to OP with Django right now
> , it would be a hard sell to invest in Ruby ecosystem instead of Python
Why? The Ruby ecosystem is great, as good as ever. What do you think it's missing?
Excellent write up.
I worked with Rails and Phoenix in their early days and got plenty of value from each. If you're building a traditional web 2 app, look no further...similar to choosing Postgres, start there until you have really good reason to venture off.
Without taking away anything from these frameworks and as someone that spent over 10 years building app frameworks, sometimes it's not what I want.
I'm using Clojure for my current problem space which would stymy me if I tried to use Rails or Phoenix. I spent the past 4 months doing product/domain "shaping". There are no web pages yet..mostly pure server side domain and API calls for data gathering. After this exploration I now have several working subsystems and have figured out the pathway to the mvp which will come together quickly. As a bonus I have a working domain core to leverage for steps after the mvp.
It’s funny you mention clojure, cause I when I saw “one-person framework” I instantly thought of Biff.
I haven’t used Biff (clojure web framework, does not sound comparable to rails), but there’s a great episode of The Repl with the dev who created it. It’s one of those interviews that reminds you how fun and creative programming can be
Episode 48 for anyone else who's interested: https://www.therepl.net/episodes/48/
Joy was a key reason I chose Clojure.
I had to google the definition of "stymy".
I've always seen it spelled stymie, was pretty surprised that stymy is legit and apparently is the American English way of spelling it.
As an American, I've never seen that spelling, and I can't find much evidence that it's an accepted spelling. I'm curious how you came to that conclusion.
"Stymy" doesn't appear in Merriam-Webster [0] nor the OED [1]. Wiktionary [2] and Dictionary.com [3] do list it as "variant" or "alternative" spellings, but with no indication that it's an American spelling.
[0] https://www.merriam-webster.com/dictionary/stymy
[1] https://www.oed.com/search/dictionary/?q=stymy
[2] https://en.m.wiktionary.org/wiki/stymy
[3] https://www.dictionary.com/browse/stymy
Reading through the list of Google web search results, collinsdictionary.com said it was American English. I should have put my faith in chatgpt instead of google search.
I would argue that framework isn't the winning component, the people are. A lot of people can say similar things for framework <<X>> and they'd be right given their own experience but I think they give themseleves too little credit. I've written my own frameworks for smaller projects because I didn't want the needless learning curve / cruft of a generalized framework and I can tell you they saved me so much time / effort / cost over the long term and they were tuned to my development style. All built with python and some off-the-shelf libraries. I'm not saying there's no place for generalized frameworks. They do help streamline development efforts and set a standardized model for building out your app/service which would be great with a team of people all tuned in to a specific framework but I would argue that in a single developer environment it doesn't matter much what you use, so long as you have fun with it. Productivity analyses are at best personal opinions in a forum like this.
Edit: basic grammar.
I'm currently building out an app using AdonisJS. Its billed as a Rails like experience but in node. https://adonisjs.com/
I did a comparison between Rails, Adonis and Fiber (a Go "framework") before settling on Adonis (mostly due to node ecosystem and type safety).
It's been excellent so far, and the creator has an excellent series of tutorial videos that can get you up to speed quickly https://www.youtube.com/watch?app=desktop&v=jf5hHU0KT3Q. The documentation is also good. LLMs can get tripped up by older versions which you need to look out for.
I found the lack of 1st party auth system annoying. Phoenix, for example gives me a nice starting point (even magic links soon). Adonis for all its features, turns me to what I hate. The JS auth implementations.
Yeah, dealing with auth can be painful. The adonis provided auth and bouncer do a decent job of abstracting some of that away, but like most js implementations, it's got rough edges (the docs and vids really help).
I'm not familiar with Elixir/Phoenix, but from reading other recommendations in this thread and after having a quick look, I need to take a closer look :-)
Is there a 1st party auth package? I can't remember any - They were guiding you to the adoniscasts videos, which some are paid. Very hard to get traction like this.
For anyone who's ducked out of Rails World over the last decade (or two), I devoted my final conference talk last year to the topic of One-Person Framework with a real-world case study of how Rails 7+ specifically helps developers build ambitious apps, even as a solo developer. https://justin.searls.co/tubes/2024-11-09-11h03m00s/
Rails is, if I'm being honest, better than Django in a lot of ways. Hotwire, the new SOLID cache/queue, turbo-native, etc.. But I still prefer the overall python ecosystem.
I'm currently building an application to launch it soonish. I'm using Rails and doing everything myself (save for the design of the logo, and some input from a friend on UX).
What's more is that I'm building mobile applications using Hotwire Native. I'm a solo developer building 2 mobile apps(iOS and Android), supported by a fully functional web application and done with vanilla Rails with Hotwire Native.
I'm surprised how well Rails ecosystem is suited to do everything nowadays.
I just wish Ruby had something with the widespread adoption of TypeScript. Once a project gets large enough it's really painful not having types
Sorbet and RBS are okay but they don't really compare
The way I describe language types to non-coders inquiring about language selection for a given project is simply “scale matters”… dynamic types provide flexibility at small scale, but can very easily result in chaos at a large scale. Conversely, the structure of static types can feel onerous and restrictive at small scale, but provide robustness and structure at large scale.
If you mean codebase complexity and team size... then yes... types is more helpful with that. But in a small team with a small codebase you don't need types to do really well. I find types helped a lot when multiple teams were responsible for different domain spaces inside different components of a Rails app. I never saw the same advantage in codebases that are much smaller with fewer people.
If you can keep everything in your head, types can feel superfluous. Large projects make that nigh impossible.
I see what you mean but I have never found it to be an issue even in large codebases. Sorbet and RBS have been problematic. Lots of development slows down with these solutions. I wished it had something baked into the language as well but I'm happy without... just following conventions alone has worked really well for me.
Yeah I just can't go back. How fast you can confidently refactor and the improved tooling is the biggest thing for me
You can do fine without them - Basecamp proved that. There's a good reason basically every other Rails company eventually moved to static typing though
Jake Zimmerman wrote this excellent blog post[1] on the current state of Sorbet.
I was impressed at recent changes in the Sorbet syntax but also with the proposal that we make code comments available to the ruby VM.
That would allow Sorbet to adopt the rbs-inline comment syntax for both runtime checks and static analysis.
So there does appear to be a way forward on this, which is pretty exciting.
1. https://blog.jez.io/history-of-sorbet-syntax/
What made you choose Hotwire over Capacitor?
I started my app using Rails and Hotwire/Stimulus and honestly finding myself way more productive than I did with more JS heavy options. Everything just works so nicely together in the Rails world.
I don't know if the framework really matters that much?
Just choose anything popular and there should be plenty of help available.
I've been using Laravel for about 11 years now. I hate it, but it keeps on trucking along so I've resisted the urge to do a complete rewrite. I don't think anything is particularly slow to develop.
It's the business side of things that's the hard part.
It matters a lot. I attribute my success at running a one-man business to Laravel (inspired by Rails). Having a batteries-included framework designed to support high-level business goals reduces so much cognitive load and the amount of code you need to write. Previously I had 10+ years of experience writing apps in basic Python frameworks like Flask but I would need to spend far more time writing code to implement basic features. Another thing that drastically reduces complexity is having the backend and frontend in a single codebase. In Rails that is achieved with Turbolinks and in Laravel it’s done with Livewire. It reduces code complexity by a factor of 2x at least (in practice it’s like 10x simpler compounded over years of maintenance).
If you hate it, don't torment yourself....make a business case to switch. Better developer productivity is a thing.
When I moved from PHP to Ruby (and Rails), I discovered how much fun programming can be. Ruby just optimizes for the right thing, Developer happiness.
I have heard that for years and I just don't get it. Magic abounds. The test assertions and testing libraries are whole DSLs that require a separate/additional learning process with inconsistent chaining with inconsistent return types. Being able to overwrite anything in the language gives rise to things like unicode whitespace being misinterpreted as an undefined function. You can define methods by combining method names leading to wholly undiscoverable methods because "my_func_that_is_cool" is actually defined over multiple files, combining my_func and that_is_cool; saw this a lot in our chef cookbooks. Ruby requires mountains of tests (thus the DSLs). Knowing ruby and knowing rails and knowing how to test are different things.
I find ruby (and rails) to bring the opposite of joy. I find myself frustrated. On the opposite end of magic is Go. I love Go. Tests are just code; no magic needed, not even mocks. Methods behave and usage is consistent. Code is navigable. Types make everything more explicit and easy to follow and more maintainable.
I assert Go leads to org happiness, letting teams work together productively.
Is there any other framework which can claim that it compares well to Ruby on Rails speed of development? I.e. conventions over configurations? Asking as I don’t want to learn ruby
Elixir Phoenix https://x.com/whizzaf/status/1916541502408323313
Elixir + Phoenix is amazing. It's one self-contained stack. Just Elixir processes (and Postgres) which takes care of everything other ecosystems farm out to extra services. Background jobs, real-time channels, and even hot-code deployments run natively within the same BEAM runtime.
Working with this with a small team with one simple stack is a breath of fresh air in today's world.
Wow that does sound pretty sick.
I’ve always heard awesome things about elixir/beam but I only have so much love in my heart for languages without good static types. Right now that love goes to clojure!
I’ve been hearing some buzz about static types landing in elixir, and it’s definitely piquing my interest. This comment of yours has fully sold me though!
This was my first impression too but I wasn't sure it covered the OPs convention over configuration stipulation.
Elixir/Phoenix is far and away my favorite framework to build with, but it does leave some things up to the user in a way that Rails doesn't, eg: there is no automatic `class name -> db table` mapping, or automatically inferring what partial or form names to use by a variables name.
In my mind, this is not a downside and there are still idiomatic ways to write Phoenix code, but just to outline some philosophical differences I guess. In the end I much prefer it because everything's a bit more explicit and flexible when I want it.
I think Phoenix also expects read documentation around OTP if you want to really achieve high leverage. This is worth it, and you can sort of drip feed yourself by starting with Phoenix, recognising that Phoenix primitives [sic] are actually Elixir primitives are actually just OTP primitives and you end up with some pretty good examples of how OTP works in a system you're already familiar with.
I highly recommend checking out Elixir & Phoenix.
I've been slowly / occasionally dipping my feet into Elixir / Phoenix dev over the past year or two, building an app idea that's been floating around in my head for a while. It's a bit of a steep learning curve for me, coming mainly from Python land (Django / Flask / FastAPI); I understand that it's designed to be a gentler learning curve for those coming from Ruby / Rails land. Phoenix is also a lot less mature / less feature-complete / less thoroughly-documented (than I had hoped, and) than Django / Rails (many of my Phoenix questions I've only found answers for in the forums, rather than in the official docs). Nevertheless, I agree, BEAM / Elixir / Phoenix is awesome, I'm hoping to get into it more in future.
I had the opposite experience coming from Django/Flask to Elixir/Phoenix. I found it very comfortable and that there were many similar patterns at the framework level. Now, LiveView is a bit of a different story but basic Phoenix routing and views seem quite similar to Django routing and views. Ecto's model schemas have a decent amount of overlap with Django's model objects.
Was it the LiveView stuff that felt foreign? I'd agree there's a learning curve there as someone coming from Django.
Laravel. Massive batteries included ecosystem and the mental model for PHP programming fits the web so freaking good. Rails 8 tried to catch up by beginning to shape the first party queue story, while Laravel has been there for a decade and the tools have been vetted at scale.
For a skilled developer who knows any of the major MVC web frameworks, they’re all really productive, just in slightly different ways.
One big up for Laravel and also Symfony, the other big PHP framework!
And now with InertiaJS, there are no more API endpoints necessary for any UI stuff. The data just gets prepared in the controller in PHP and gets directly loaded as JSON into the React/Vue/Svelte frontend pages, thats it!
In each of the dynamic frameworks I have worked in, besides lacking types, the biggest problem is domain separation.
In 4 out of six large, dynamic code bases I have worked in, everything becomes spaghetti. This joins with that which n+1s with yadda yadda. You end up with dependencies that prevent billing options because you can't separate the billing structure from the user model from the product table. Queries start joining and joining and you get monstrosities of queries. The beefy postgres db gets bogged down at less than 2k rps. Everything gets slower. Then the org spends millions and millions on domain separation and breaking teams away from another. Builds get slower. Competing styles of decomposition litter the codebase. Changes take days to release. It takes Herculean effort and heroics to fix a dynamic code bases that grows, eating at growth when it should be compounding.
"But it let us get here, where we can afford to do those changes." Maybe. It is the road less taken's point - you can sell yourself that the dynamic code bases allowed for the success. But that doesn't say the alternative wouldn't work.
</insomnia thoughts>
I’ve been asking this question for a while since I love Rails but I don’t like Ruby that much. I think only Django comes close, although I haven’t tried it, but I dislike Python much more than Ruby.
There are always attempts in every language to replicate the convention over configuration and batteries included approach of Rails, but they all lose steam pretty quickly.
I just don’t think there is an alternative to Rails. It’s a giant project that is actively developed for over 2 decades now.
In elixir -> phoenix, python -> django, php -> laravel.
Any other ones are gonna be a little niche but from what I can tell these four (with rails) have the most large and active communities atm.
I have a proprietary one that's much faster in terms of dev velocity.
When I struck out on my own I realised that I no longer had team consideration as a constraint and went a little bit off the beaten path.
Every client I have used it for has had nothing but praise for how maintainable the software is.
Possibly Laravel, but then you’d have to learn PHP! :D
All jokes aside, having worked in both languages and frameworks, I’ve enjoyed the Dev experience in either option.
Grateful for both dev communities as well.
I used to code ruby. Now in python land and am using flask. Theres conventions but no scaffolding. Ai code tools make the scaffolding feel redundant anyway.
Coming from Ruby, Flask is much more of a Sinatra than a Rails. It’s very batteries-not-included. You basically just get routing out of the box. DB ORM, forms, auth, mail, background task, etc. are all DIY. That said, there are high quality packages to do all of those things within the ecosystem and I really like that I don’t feel like I have so much unused bloat in the framework when I’m making a small service.
In Rust we have loco[1], that aims to be a Rails for Rust. I personally have never built anything serious with it, but all the toys projects were pretty enjoyable.
1- https://loco.rs
I'm 15,000 lines into a Rust project at the moment. I like it a lot but I'd never consider it for a web centric app.
Mind to share why?
As someone who likes Rust, has one project (web based) in production in Rust, and considering starting another one, I'd be glad to learn from the experience of other people.
I have several apps in production. I employ sqlx, axum, async_graphql, React frontend.
So far I don't know any better way of doing it and I have tried all the classic ways like PHP, Django etc. This is way superior. The only downside is that I am the only one who can touch the backend, but I guess if some of the projects grows enough, there will be enough incentives to find another Rust programmer besides me.
Yes, this mirrors my experience as well. It's just every time I see someone who "quits" Rust in order to go back to Ruby/PHP/Python, I'm interested to know what part they were struggling with.
If we raced, me driving Laravel and another dev driving Rails, we would be neck and neck in terms of speed and quality.
If you value types more than completeness, Krop is a framework for Scala: https://www.creativescala.org/krop/ It's only suitable for very brave developers at this point in time, as it is nowhere near to feature complete.
Meteor.js offers pretty good iteration speeds and a fairly complete toolbox for the JS world. Fully featured accounts system, RPCs, client/server reactivity, etc.
It's niche, but check out https://www.boxlang.io/ and https://www.lucee.org/ on the JVM. They're rock solid runtimes. I single handedly manage multiple production applications going on 10+ years. They essentially never break, never need major maintenance. Backwards compatibility is great. The runtimes are very batteries included in terms of backend web development.
I’m curious if .NET can compare here, though I have limited experience with rails or ASP.NET both seem to give you a lot to work with. Though the overlap of rails devs with .NET devs seems minimal.
I learned to code professionally in Ruby but wrote C# .Net for almost 10 years. I've probably forgotten more about .Net than I ever learned about Ruby at this point so take what I say with a grain of salt.
.Net has tons of configuration and boilerplate so I can't say that it's exactly the same in that sense, but the more meta theme is that just as there is a Rails way to do things, there is a Microsoft way to do things. Unlike Java where you're relying on lots of third party packages that while well maintained, aren't owned by the same company that does the language, framework, ORM, database, cloud provider, IDE and so on. Having a solid well documented default option that will work for 99% of use cases takes a lot of the load of decision making off your shoulders and also means you'll have plenty of solid documentation and examples you can follow. I've been in JVM land for the past couple years and it just can't compare.
I know Java people will come fight with me after this but I just don't think they know any better.
I don't want to fight you, because I don't know .Net well enough to have an opinion.
But I just want to say that I have the same feel when I develop using Spring Boot. I am extremely productive and seldom have to pull dependencies outside Spring for 80% of what I make.
I think the Java people would say that if you want one way to do things, go do it the Microsoft way :)
But I guess Spring tried to do that, but probably didn't have the resources that Microsoft does.
I still don't get why .NET barely ever gets mentioned in these threads. Even new or niche frameworks like Phoenix, loco.rs and others get mentioned, but almost never .NET. It's as "convention over configuration" as it gets.
Platform support and open-sourcedness. The Phoenix 1.0 release predates the first open-source and Linux-supported .NET release by a year, for example. .NET is just now starting to shake off its association as a closed-source, Windows-only thing.
.NET has been open source since a decade
Yes, like I said before, Phoenix 1.0 predates the first open-source and Linux-supported .NET release by a year.
https://news.ycombinator.com/item?id=10135825
https://github.com/dotnet/core/blob/main/release-notes%2F1.0...
People aren't just going to jump onto something recently open-sourced by a company that popularized the phrase "embrace, extend, extinguish". For the last decade, they've had to earn people's goodwill, while with a project like Rails, there is no "we used to be closed source but now we're not, use our thing!" to overcome. So in the 20 years since Rails has been released, it has only ever needed to demonstrate its usefulness.
Now that a decade has past, that negative association is starting to wash away a little.
And Ruby on Rails was released 20 years ago
Asp.net core is actually pretty simple to stand up and bang something out. Stick to the Microsoft docs and most patterns are handled.
I can't really say how the web UI side holds up to alternatives, tho.
The only thing I don't like about ASP.NET is all the dependency injection, last time I looked it seemed unavoidable.
Django is more or less Python's equivalent of Rails. Its admin panel is nice, especially for a solo developer trying to manage something they built in a weekend.
Is there an equivalent of the Django admin panel in the PHP (Laravel/Symfony) world?
Filament, and it’s fucking awesome. I think it’s way better than Django’s admin panel, and I’ve used it to build out both my Laravel admin panel and basically all of the UI for users.
Django's admin is great. I think iommi is better for a lot of projects.
With admin, you basically just write models, and the entire rest of your app is free. Not quite, but, not far off.
Wasp! Still in Beta, but aiming for that RoR / Laravel DX, in JS.
I have heard Laravel is shockingly complete and most others will pale in comparison to in terms of out of the box speed to first feature and the full CI/CD setup for most any kind of product.
Speed of iteration rules above all.
Speed of iteration varies within a single projects entire lifetime.
My speed of iteration in dynamically typed languages is great at first, but after running in production for 8 years, coded by a team that never wrote the original, dynamic typing hurts iteration speed.
If you judge iteration speed by how fast you get to feature #3, I've got a ton of bash programs that will beat any serious language product you have on that metric.
Speed of iteration is for speed of feedback and insight from the business/market into the product.
That can be a mix of how you see it, how the business works and how the code does anything.
It is important to understand I’m not referring to dynamically vs statically typed languages or not. It’s a distraction. Code runs fast on pretty much anything these days, and dynamically typed languages have pre-compilers.
These are sometimes matters of personal experience, interpretation, preference and opinion masquerading as facts.
Most languages have to abstract from to the web using a framework and that additional interpretation is where a lot is lost.
Featuritis is the disease, solving problems solely based on customer input (who are strangers) is important. Problems are rarely a single feature, but a sequence or group of them.
The irony of bash scripts is they can be some of the most durable and well lasting parts of a project while everything around it might change and evolve quicker. So if there’s some bash scripts being called by a language in the beginning.. so what.
My original point about Laravel is I have not seen as tightly integrated of any ecosystem to ship solutions and product where so much time is not lost in the product side of it (accounts, billing, migrations, etc). While I’m relatively new to it, at the very least it’s a worth comparison to show the holes in others.
Laravel is a great way to run apps as a one person team
Phoenix or Meteor.js
Django is the closest I can think of. Many unicorns built on Django.
Both Rails and Django are horribly slow though, so once you get to some critical scale you gotta start doing some real weird stuff like Instagram did with turning off Python's GC [1], etc.
[1] https://instagram-engineering.com/copy-on-write-friendly-pyt...
Regarding the slowness, I think it's super important when working with slow stuff like Django to have good SLOs in your head.
"Home page should load under 2 seconds at P95", "reports should load under 10 seconds at P99", "this background task should take under 30 seconds at P99".
Having these targets (and, frankly, remembering in the B2B space is that the status quo is _so slow_) can let you set performance objectives without chasing milliseconds that you don't need to.
Django has a lot of intrinsic slowness to it, "easy" DB access patterns often lead to heavy messes, but if at the end of the day most customers are getting served under some benchmark you can reap the advantages of the tooling without sweating perf too much.
And when you set these SLOs, you can then push for even tighter ones as you figure out your problem space!
In the B2B space companies get away with _so much_ sluggish behavior, if you're better than the median that's already improving things.
My previous company had a sizeable Django monolith and did e-commerce stuff which is fairly latency sensitive. Used well, Django was perfectly capable of hitting 150ms per page which was fine for us. Some optimised pages were under 100ms.
Things we did: careful about N+1 queries, caching where obvious, API calls/emails/etc running in background queues.
Things we didn’t do: use a fast templating language (we used Django’s built in one and it was often our bottleneck), removing all database queries (we just had Postgres <2ms latency away), renormalising data (we were highly relational for most things).
Django is perfectly performant enough for almost all use cases, and insanely fast to develop with.
Yeah you can make Django go really fast, especially when you have pages that well scope what data they are pulling from (though you seem to know it better than me).
I think B2B SaaS, for "normal" teams (read: people not that adept at building scalable systems), when not careful, tend to make omnipages where about 20 different things are happening. Even just navigating to a page ends up triggering random side effects (driven by various needs).
There you can easily find yourself in a performance pit that you have to dig yourself out of (often redesigning features in the process to remove some stuff).
I just find that setting fairly easy performance goals can help to make perf seem more tractable.
Most slow queries / endpoints / things can be cached! But, of course, every time you stick a cache in front of something, now you have two problems...
"horribly slow" yet some massive websites run on both.
How does a solo developer/maintainer with a production app and thousands of active users take a "disconnected" long-week vacation?
Build something that works and that doesn't need a person to be around to support it.
Or just don't offer support. :)
I see a lot of love for Elixir/Phoenix floating around but oft posted is that Ruby is just an easier and more approachable language for many people.
I think that aside from Rails, that makes it one of the easiest languages to pick up and have fun with. I do miss my Rails days for that reason.
I use Django with Vue CDN for the MVP. The framework is similar to RoR. The key is not about the framework IMO, but whether you pick up a good track. If the demand is great, you can feel the pull from the market. Otherwise, whatever framework can't save you from failure.
I'd need the opinion of someone who's worked with other acclaimed technologies (his was PHP) to tell me that Rails is indeed that much better
Developer experience and the choice to keep complexity low make a much bigger difference. The things Rails solves for you are, these days, solved problems in all mature languages that are used in web development
(coming from close to a decade of Rails experience on my end)
Not what you asked for. But I could write a very similar article about Laravel.
I run multiple apps as single developer and Laravel has a great community.
Laravel has a lot of similarities to Rails.
Having worked as a basically one person Rails shop I think one of the things that makes a big difference on productivity is whether you can say no to the big react front end or not. (And I say that having come to like GQL: It's still like 5x the workload to have a react app + Rails back end.)
> Sticking with a well-structured monolith was one of my best decisions.
I can't emphasize this enough. Did the same with a monolithic PHP application. David Heinemeier Hanson used the term 'majestic monolith' and it really feels like that, working on some cathedral in code.
Congrats on your good choices and results. A programming language that you like is important, but I think you should give your own decision making some more credit.
In large regards, this is basically my dream life. I just do not know where to start/what to write honestly.
Buy then.
Correct link: https://bramjetten.dev/articles/the-one-person-framework-in-...
I think you're not giving yourself enough credits and you're giving Rails too much.
I know a developer who followed a similar approach in PHP.
A relative of mine is running his company as a single dev in node.js + react.
My company runs on Python.
The key skill is being a good generalist willing and capable to do all the roles you need. Every tech stack can be automated for most small business needs, so that you can reduce the time spent on it.
I agree. Nothing beats using a well known framework for speed.
I think we also need to consider how much experience one has with a language. Most can pickup a new language relatively quickly, but it's not the same as having real experience with it.
At work, someone just started a new micro service written in Rust because they were familiar with Rust and thought they would be able to do something "fast". They spent at least half the time struggling with even basic dependencies, how to deploy it, monitor it and make it deployable. If this was a startup, they would have burned a significant amount of time that could have been spent on PMF
Honojs is another good one.
No depdancies. Frontend react as well as SSR included as jsx. Faster than fastify. JS/ES/TS runtime agonstic. Native tsx jsx support.
Hono doesn’t give you even 25% of what a framework like Rails does
Those type signatures mismatches on the handler still bring me nightmares.
Hono really needs something like axum's debug_handler
Is it just me or is Hono being astroturfed pretty heavily on HN lately
[dead]
[dead]
Rails is unmatched. I wish there was just a similar framework in a faster language.
Ruby is plenty fast these days (people usually think Ruby didn't get faster but it did). And if we figure out how to switch to async/fibers with let's say Falcon, we are in a good place :)
Ruby isn't standing still in terms of performance either. YJIT is getting better all the time and ZJIT is on the horizon too.
For concurrency, async fibres are brilliant but not the only game in town.
Using good old processes works really well in Pitchfork or alternatively JRuby and TruffleRuby both have true non-blocking parallelism right now using Threads.
If anything TruffleRuby shows that there is nothing inherient in the Ruby language that means it cannot catch up in performance terms.
Speed of the language is not a problem for 99% of projects
Loco? https://loco.rs/
Elixir + Phoenix?
Indeed. Runtime is typically a lot faster than Rails. Response times in dev mode are <1ms which is fun to see coming from Rails :)
My personal dev speed however is a little slower in Phoenix than Rails. And I've been using Rails for almost 20 years and Elixir for 10.
There are categories of problems that are much easier in Elixir (High concurrency, low latency, etc) and for those I would always pick Elixir. If you're planning "just" a crud like web application, Ruby will probably get you to product-market-fit faster. There are (well maintained) gems for almost everything.
Laravel or Symfony using PHP
Let’s be clear - the success is not because of Ruby on Rails.
You could build the same thing with nodes or python or golang or whatever.
There’s nothing special about rails, except that the developers speak like it’s special.
There’s nothing that can be quantified in any tangible way to indicate it’s actually better in any way. Rails has enthusiastic words, but it’s not actually better.
It's part of the success. There's a reason you don't hear similar 1-person stories with Express.