Rails (and possibly Django and Laravel) are just light-years ahead of any other stack for building web apps. They have dealt with all the tedium, know all the requirements, and actually get out of your face when building an application. I have been developing web apps for 15 years now.
I have tried Meteor (back in the day), Remix, Nextjs, Node w/ Express, etc. Always talking about how much better they are. But in my mind web dev is a solved problem. The js stuff is mainly just developers wanking off, driven by a bunch of dollars from big companies.
Systems stuff, deployment infra, etc. is great for stuff like Rust & Go, but shoehorning into web dev makes no sense. I would love to just move on from this debate but it seems thats going to never be possible.
Unfortunately every team I’ve worked in hasn’t seen the light and prefers FastAPI/SQLAlchemy/Pydantic (before FastAPI it was Flask).
My theory is that the initial learning curves are different: with FastAPI it’s quick and easy. You barely have to read anything. Django has a steeper learning curve. There’s a lot of reading involved. Type hints aren’t a big thing in Django, but they are in FastAPI, and the average full stack dev seems to like them.
Later on it’s totally different of course. With FastAPI you’re building it all from scratch, and it’ll be much worse than the Django solution.
Type hints are were the whole Python ecosystem is going, so using them is more integration at a deeper level than using an integrated framework, which is not relying on them.
SQLAlchemy was historically a much better ORM than Django's. It's layered architecture combined with Alembic does make a difference.
I still agree that using the integrated thing anyway is probably the right way to do it if you are working in a team. I also think Django should just adopt these components and we would not have the discussion in the first place.
As someone that used AOLServer, was in a startup doing something like Rails but in 1999 with Tcl, I don't really agree.
The Rails demo wasn't that appealing to me, other than showing the difference on how lucky one might get regarding adoption and spotlight being in the right place.
Nowadays I still don't see a value, and rather go for Spring or ASP.NET.
By the way, the founders of that Tcl based startup, went on to create OutSystems, which is one of the few successful RAD tools for Web development at enterprise scale, and Portuguese success stories in IT world.
From my experience, these frameworks are like the express lane for kicking off a project because there are no big decisions to make. But once you’re knee-deep in Rails, Django, or Laravel and need to do something off the beaten path, things can get dicey. Why? Because you didn’t write the glue code yourself, so there's a gap in understanding, not really a technical roadblock (most of the time!). My point is, if you dive into these frameworks and actually learn the guts, you'll save yourself tons of time coding by, well, reading code.
Now, do I actually do this? Absolutely not. Rewriting everything is way too much fun, and I live for the thrill of trying new things, even if it makes zero business sense.
I must say that even if it’s not a trendy stack, I find Spring Framework/Spring Boot to be the best all-around web application stack. Very easy integration with the tons of java libs you have around that can do virtually anything, a statically typed language which can help in a lot of situations (just data binding by convention via Jackson is great since forever, while it’s an afterthought in dynamically typed languages).
I've been incredibly pleased with Ktor and Kotlin, as well. JVM underneath, robust libraries, easy to use infra, using Exposed for the ORM which is mostly (genuinely) a joy.
The best thing I think Rails still has is ActiveAdmin. Everything else, I really can take or leave.
> The best thing I think Rails still has is ActiveAdmin. Everything else, I really can take or leave.
ActiveAdmin gets you off the ground very quickly, but is also extremely inflexible (and, IIRC, poorly maintained). The last time I worked on an ActiveAdmin backend we had to use all sorts of weird hacks to build the interface the way our backoffice team needed it to be.
I did write a lot of Java but never called myself a Java developer, and in my current company there are a lot of hardcore Java devs who used to swear by the Spring stack (some even liked JSF!), and a lot of them are moving things to Quarkus (https://quarkus.io/). No idea why, just an observation.
They are moving there because it's new and shiny, not because it's better.
Spring and Spring Boot are incredibly productive and give you a ton of stuff out of the box, whereas some people actually enjoy writing a lot of plumbing code as a distraction/challenge from boring business code. Those people will migrate to "lean" frameworks because it will give them the opportunity to write more low-level plumbing code.
That sort of proves my point, though. Spring support for GraalVM is ongoing and will likely be quite useable and mature out of the box.
The people jumping to Quarkus or Micronaut are more eager to chase the new shiny and are willing to spend the time debugging not-yet-mature stacks.
Edit: To be clear, the reply mentions fanboyism but we are talking about the maturity of a stack. Spring has been around for 20 years and is not going anywhere. Quarkus just reached 5.
The GraalVM is significantly more performant. Calling that "chasing the new shiny" redefines the meaning of the expression, which has historically been about side-grades for unclear advantages.
Especially considering that Springs support isn't full yet, and quarkus has been around for 5yrs now.
They're both production ready stacks though, really strange to have spring fanboyism in 2024
I do not agree. Rails is absolutely great in terms of features and productivity, but will fail you elsewhere i.e. it is not the silver bullet for webdev. Do not take my opinion, look at data - https://www.youtube.com/watch?v=Qp9SOOtgmS4
If you are using Rails for anything where you are not absolutely sure of how many users or RPS you will have, you are just saving money in launch time but spending more on servers.
Everything can scale if you throw enough servers at it. Of-course Shopify scales, they even spent time and money to build a JIT on top of Ruby. As a smaller company, does everyone have the time and money to spend on servers or optimising the language to this extent?
Smaller companies have less traffic, need less expensive servers, and have no need to spend money optimising the language. They can focus on that when they make billions of dollars, like Shopify does.
If RPS become a problem you can probably switch to JRuby. I did exactly this 15 years ago for EUs biggest software company and it worked out quite well.
Have you seen the latest state of JRuby development or seen the posts of its development team. If you are comfortable with the idea of your main runtime being dependent on the time / finances / availability of around 5 (or less) core developers I would say you are ok with JRuby.
I came through to note that most of this applies to Django, too.
I've historically preferred RoR but with the tremendous growth of Python in the last 10+ years, Django has become a more practical choice. ML and data science devs are already familiar with Python and, with the Django docs being as excellent as they are, these folks can be productive in a very short amount of time -- should they need to be. I've seen this firsthand on multiple projects.
Also, along with the author's case for the path of least resistance, the Django framework results in fewer "decisions" (arguments) about application structure than using a less opinionated library or micro-framework.
The Django/FLOSS community is also much more active than I was expecting it to be (Rails bias, probably) and has been very pleasant to interact with.
I only wish Django had Rails-like generators and in-built data seeding (e.g. rake db:seed).
I like the rails dev experience, but it feels like they haven’t come up with nice new front end solutions that an integrated framework like nextjs has done.
One specific example is images and srcset. If you are doing a react front end anywhere in your app (not even an SPA) interfacing with the asset pipeline doesn’t have a canonical solution.
This just makes it feel behind the times, since what I always liked about rails was the “one right way” that was always reasonably sane.
So it feels like nowadays you need to trade user functional front end app things, like load time and LCP for dev experience in rails. Sad.
I disagree. Rails is fine but just a differential approach. I prefer a standalone fronted that talks to an api layer. Web Frontend for me is remix. Mobile is react native and api layer could be any language you're productive in, eg. Java,.net or javascript.
I'm working with Rails for 17 years now, still love it and still prefer it even for the frontend. It give you all the options to separate your code without the head of your files becoming a unnecessary long list of `includes` like I see in the angular app I have to work on for a client. I don't see a disadvantage in splitting logic and markup for the frontend, it allows you to test the logic independently and normally when you hunt a bug you should know whether it's in the markup or the logic. Tracking down a bug thus becomes more easy.
I've written my fair share of far too long ruby methods, 200 lines and more, but those are truly my fault. With a more granular unit test regime those can be prevented.
You know what else allows you to avoid having that long list of includes? Making everything global. I'm not sure if I see this as a benefit. Imports can take up a lot of space, yes, but they also make it explicit how everything ties together. If they're in your way, you can always have your IDE collapse them.
Rust is a language built by extremely smart people, unfortunately their focus is more on type theory and sparing few allocations than building something useful and coherent for blue collar devs like me. When I read a blog post on rust, I literally don't understand half of it, although I'm working with rust since 2020.
The reason NextJS and similar tech like SvelteKit are so popular amongst JS developers is that they alleviate the problem of Node.JS not having a great backend development experience. Building a backend in Typescript is like building it in C#, but without the advantages of a properly designed language. The experience of building a backend in Rails is miles away.
Node.JS developers are starting to realize it's not just about having the ecosystem and the tooling, it's also about the framework being a holistic solution to building out your application. That's what NextJS and SvelteKit help with, and that's what Rails revolutionized back in 2006.
While it is thoughtfully designed, its type system has been designed under the severe constraint that it must be retrofittable on typical JavaScript code.
> Your comment doesn’t advance the conversation in any way.
That's oddly rude. I thought it might be useful to someone (not necessarily you) to bring up the fact that TypeScript is subject to a very different pressure than most other mainstream languages. That has obviously resulted in a very different type system, e.g., one with much better support for structural typing than most mainstream languages.
> It just restates the claim that typescript is worse in some unspecified way.
I did not "restate that claim". In fact, I was careful not to claim that TypeScript is "worse" than any other language, because that's a meaningless word without more context.
> Can you give any examples of ways in which those constraints have resulted in a worse language?
Again, saying that it's "worse" or "better" without context is meaningless.
Well it’s bolted on for a start so introduces overhead from the get go. Its type system is also severely hamstrung and complicated by JS compatibility. It doesn’t really compare to Rust, Swift, OCaml etc.
You say that, but its type system has some wonderful feature that those other languages lack. In what way is it hamstrung? It seems better than C# to me!
For example, C# doesn’t support parameterised enums like typescript and rust do. Once you start using parameterised enums, you seriously can’t go back. It’s a killer feature.
But even then, typescript goes further. All of these languages let me make a Color enum with red, green and blue variants. But as far as I know, only typescript will let me write a function which takes a strict subset of those variants. In typescript I can have a function that only accepts red or blue - and passing green (or something that might be green) would be a compilation error.
Typescript also lets you make another type with a superset of another type’s variants. Eg type Foo = Color | “yellow”.
In rust if I want to change a function’s signature to make one of the parameters optional, that’s a breaking api change since all existing callers need to wrap the parameter in Some(val). But in typescript, I just change the parameter’s type from T to T | null and everything works.
Again, in what way is it hamstring? I’ll grant that JavaScript doesn’t have quite the performance of C# (though modern runtimes are pretty impressive!). But typescript itself seems great.
> That's what NextJS and SvelteKit help with, and that's what Rails revolutionized back in 2006.
Are you seriously comparing "being able to execute code on the backend" with Rails? Or Django? Or Laravel?
There's no way in this world Next/Remix/etc are helping in any way to write code on the backend. Where's the support for database access? migrations? ORM? queues? scheduled jobs? validations? translations? authentication? authorization?
The only thing Next.js is helping with is pushing people towards Vercel's platform, that's it.
Great real world article. Everybody should keep the bottom line "under their pillow":
>> Interestingly, all of the things that used to annoy me about Ruby and Rails now annoy me much, much, much less. I have accepted that there is no perfect language or framework. You just have to know its strengths and weaknesses and deal with them.
A little gem of an article, thanks for posting. It's nice to see a pragmatic take on rewriting for a change. Feels like a good primer to read before considering a rewrite myself haha
Regarding rewrites, I'd love to have my code in such a shape that I could just copy over the business logic, maybe even put it into an independent library. The rest is just a user/api interface after all.
When people nag about frameworks I usually think that have their “perfect” world idea they don’t want compromise. Lots of times it is not having full understanding of the framework and why’s.
But it is much more efficient working with the framework, knowing its limitations. Just spending time really understanding tools one work with.
Writing large web applications in Rust isn't going to happen fast. Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend.
Choosing something like Java, C# or Go might not sound sexy or cool, but with get the job done as fast as Rails while running almost as fast as Rust. That choice will also generally mean less bugs and a having a project that is easy to maintain and extend.
> Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend.
With care, none of that is necessarily true. I think that's an overgeneralisation.
I've worked with many large, bug free, stable and easy to modify rails apps. I've also worked with messy rats nests rails apps, and go apps, etc.
It can be true that some languages/frameworks make it easier to get into that state, but all have a chance to make that a possibility, or other trade offs that make it difficult to build with for other reasons. With discipline you can make anything work.
I think the biggest difference for me is that when there's a rat's nest of a Rails application, refactoring it becomes the hell of type errors and writing tests that, frankly, a compiler would catch.
And with sufficiently large applications, those issues really start to spread through the whole program - or can.
addendum: I'd love to know why I'm getting downvoted here. I definitely speak from experience, here.
I guess my point was that, with discipline, it's not a foregone conclusion that a Rails app is going to be a rats nest. The lows can be pretty low for sure. But it's one of the tradeoffs for the framework and one that can be mitigated with thought and effort.
This is my experience as well. Rails makes it incredibly easy to get a web app off the ground but as it grows and adds more features and complex business logic it becomes much more difficult to maintain than a codebase with static type checking.
You can't be seriously saying using "Go" (a low level systems language) will be as productive as using Rails (a very high level framework intended for CRUD applications). Despite how much you might hate Rails, that's like saying you'll build a blog faster with C++ than with WordPress.
In terms of Go or C, even Rust which is one of the only of the two used in kernel development. Migrating is in line with the principles of the CRUD methodology, whether it takes place by means of a compiler or a junior developer parsing assembly line-by-line.
Go is not a low-level systems language. Even using the more flexible modern definition of "low-level" it's not a low-level language. That's like saying OCaml is low-level; it's not even close.
You can write large applications in Rails that run fast, have low bug counts and are not hard to maintain or extend. There are many examples in the wild.
Rails is quicker to build in than Java, C# or Go for most functionality needed in most web applications for similar skilled developers. In my experience, up to 3x quicker.
I’ve worked on large monoliths and SOAs, and worked alongside Java teams. I even introduced Go to a Rails shop because I believed what you did.
Turns out the real problems were MVC isn’t right for everything, and we weren’t name-spacing with enough rigour. Fix those in small and targeted areas, and Rails is just fine.
> Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend.
I have never used BaseCamp, but I believe their products are well written and decent, hence with adequate care, good architecture and maintenance, it should be possible.
I'm a little confused about the comments here saying Rust is not great for web backends. I've had the opposite experience, building mostly small services like beampaint.com and probablyup.net. Maybe the complexity goes way up once you try to build a bigger app? I mean surely it does,but Rust is great at giving you confidence where you need it when you have large code bases
Right, wouldn’t the difficulty go up drastically as soon as you need more framework-territory things? Because the established frameworks have them out of the box but the Rust framework is unlikely to (due to age). Imagine going from just two of those missing things to six.
I think almost always the DB query will take the longest but: I've seen too many engineers not even do basic optimizations such as creating indexes.
Here's a list of easy/low hanging fruit optimizations that are often just forgotten: Creating indexes in the db, delegating more logic to the db than doing it in code (e.g. using pipelines in mongodb, partial indexes in postgres, etc.), turning on brotli/zstd compression for all or most requests, caching objects or requests in memory (e.g. with redis), setting appropriate cache control headers, frontend stuff such as not rendering thousands of objects as DOM nodes and instead using canvas (recently saw this in a map application).
I have seen the opposite too, a db full of indexes that grew very large and was very slow on inserts! Understanding that an index is only useful on columns that you want to search might be a start!
We recently started testing AdonisJS as a TS alternative to rails.
I'd recommend anyone who'd be interested in "Rails, but in TS" to give it a go.
It feels much more similar to rails (or Laravel) than the most popular TS stacks, and also has "batteries included" instead of leaving you to decide on every part of your stack (or trust a template from a third party).
It's not a terrible choice. It's not necessarily wildly better than alternatives, but it's not wildly worse, either.
Among other reasons to consider it: if you want to run on a FaaS platorm or container setup, Rust has much faster cold start time and makes for smaller container sizes.
Among reasons to not consider it: if you want to iterate rapidly by editing text and near-instantly hot-reloading your code, Rust web frameworks aren't really there yet. They will be one day, but they're not yet.
> Among other reasons to consider it: if you want to run on a FaaS platorm or container setup, Rust has much faster cold start time and makes for smaller container sizes.
Faster start time maybe, but I’m not sure about smaller containers. Rust is terrible with binary sizes in my admittedly limited experience.
"Have many issues at runtime? Test more. Does it turn into unmaintainable spaghetti code after a while? Only if you let it. It's typically caused by developers, not programming languages or frameworks."
Yes. I'd much rather work with developers that know how to untangle and fix spaghetti, than those that have their hands held so steady by the environment that when the spaghetti does show up they don't know how to get out of it.
This is a nice enough article considered as an experience report. It’s tempting for me to focus too much on the title (was it a rewrite in an interesting sense? no, it was like going on a five-year trip across Asia and returning to your hometown to marry your high school sweetheart[1]).
It doesn’t seem like the author learnt that much. They know Rails and Rails is good for making webapps? Makes sense.
[1] For the author. The rest of the team didn’t know Rails. And there was no one on the team that knew that rewriting parts in “blazing fast”-lang would work.
Yeah, it is maybe a bit of a clickbaity title, but I thought it was relevant enough. I tried Rewriting it in Rust and ended up not finding it worth the cost. There was some rewriting in Rails, but indeed, not very much.
I did learn that things wouldn't necessarily be any better if I were to use language/framework X instead of Y.
Edit: I guess I also learned that Rails does so much for you, so you can focus on building a good product. Just gotta make sure you use it as it wants to be used as much as possible.
It’s fascinating to me to see that nowhere in this thread, at the time of writing, is mentioned what used to be the darling of web development, a language that seduced many ruby developers to crossover: Clojure. The times have changed.
To do Clojure web development was to noodle around stitching together various libraries piecemeal, i.e. the same thing that everyone who resists proper batteries-included web frameworks does.
Laravel with Filament is super productive also. Django used to be my goto for 15 years but the frontend infra, Livewire, and flexibility of Filament compared to django-admin are hard to beat.
This article is kind of the story of my life…
I launched a SaaS app written in Go in 2013 coming from Rails and I had to figure out everything on my own. Migrations, database layer, asset pipeline, deployment, validations, logging, payments and so many more things that rails just give you.
You're comparing a systems oriented barebone low level programming language to a very (maybe the most) high level framework on top of a very (maybe the most) high level language.
I'm not a fan of Go, but that's not the thing to blame here. Using Go for a "CRUD" application is a terrible decision from the get go.
I’m not blaming and I fully knew what I was getting myself into. In the end it worked out and successfully launched etc. Just took me longer and had a learning curve that made me a better developer too.
But had I wanted to just launch quickly from a business perspective Rails would have been the way as I already knew it. I still to this day like the simplicity and speed of Go.
Like every year or two I come back to Go and try to get the dev experience for my own framework right with Rails in the back of my mind but it’s tough and more of a boilerplate than a framework.
A lot of startups are making their code bases in TypeScript. And it is an unbearable mess.
I recently consulted with a company where I rewrote their app in Rails. And now it's much simpler, much better, much more extensible, and far more enjoyable for the developers to work on it.
As a Rust dev it feels like I can't rely on the Typescript compiler at all. If you don't spell everything out for it, it might silently fail to infer the type of a variable and suddenly the function returns a number array instead of a string and the compiler will be just fine with it. Not to mention runtime still has all the problems of JS.
>[...] suddenly the function returns a number array instead of a string and the compiler will be just fine with it.
The type checker is quite forgiving, but that does not sound like something it would just be fine with?
The TS type system is not sound which has obvious tradeoffs. I prefer it over Rust for most things because Rust feels like a Comic-book-guy type person looking over my shoulder going "Akshually, you didn't tell me what the lifetime of this string is", even if it is trivially obvious. I acknowledge that there are situations where that is very valuable but in my opinion it's not generally superior.
I want to try Rails but I can't downgrade away from static typing for my personal projects. I typically want to spin them out quickly and not worry about writing tests: static typing adds way too much value in that scenario.
I looked into Ruby's static typing attempts but the picture painted was grim.
Sadly, that is the reality of Ruby, no excuses. Introducing static typing to Ruby is a huge task considering the way the language is designed.
The attempts you've seen is probably Sorbet (sorbet-runtime) and RBS. In my opinion, RBS would be an option for me if they didn't force me to work in a separate file just for type declarations.
There's this weird conceit that Ruby On Rails somehow has a monopoly on developer experience, that Ruby On Rails gives developers pleasure that is unique and uncopyable - a unique and utterly amazing and incomprehensibly awesome developer experience that no other language or framework can replicate.
Rails developers smugly assert that Ruby on Rails is more productive than anything else out there.
I call BS on the "Ruby On Rails is the very best by far" conceit.
Ruby On Rails has a monopoly only on the perception that its developer experience and productivity is off the charts.
Ruby On Rails is just another language and framework. There's literally nothing that makes it different or particularly special compared to anything else.
Developers everywhere with Python or nodejs or TypeScript or C# or Golang have a developer experience that is just as great, without the high handed conceit that what they are doing is amazingly better than anything else.
SEGA used to have an advert, "To be this good takes AGES". Maybe Rails doesn't have a monopoly on having 20 years of continuous development refining it, but it's not the norm.
You pay 100x for each line of code and get nothing in return over ASP.NET Core or Vert.X. Pick any fast compiled language you like, don’t contribute to global warming.
“Don’t contribute to global warming” is the silliest argument for perf bc you can use it to dismiss basically any human leisure activity. Why is it okay to use a computer to play video games but not make the perf tradeoff with Ruby?
Because there is no trade off. Rails does not offer anything over picking Kotlin/C#/F# or even Go offerings. The “productivity” is a little excuse used to hand wave away the criticism of absolutely unacceptable state of Ruby performance in the year of 2024 and all the other problems that it has.
What do you mean? Rails seems to come with authentication, session management, cookie management, an ORM, extensive logging capabilities and a bunch of other things. Go and Kotlin are languages, not frameworks, and they certainly don't include these things. So what are you comparing exactly?
ASP.NET - maybe, but you’ve got to be kidding if you suggest Vert.x to be a replacement for RoR. They operate on completely different levels of abstraction (even ignoring nightmare of Reactive code you have to write using Vert.x).
The whole article is about how there is a tradeoff, sorry they didn’t investigate your preferred technology but you can’t expect them to try forever. Even if they had tho, are those really “batteries included” offerings like Rails?
"I couldn't horseshoe a hard systems language to replace a web framework for a CRUD app written with soft language, so I had to go back"
Rails is very good until you need to go off rails. Even in that case rewrites must be partial and not to aim to fully replace the original. Most of the time rewrites are a waste of time. This article could be true if you s/Rust/Ruby and tell the story in the opposite direction.
Didn't we make this mistake and learn from it in 2005? I guess not.
Ruby, and Rails, was an awful idea then and it's an awful idea now. Even in-browser stuff is moving to typescript to get away from having to write unit tests for basic type errors.
But sure, let's dig up this failure and try it again
Rails (and possibly Django and Laravel) are just light-years ahead of any other stack for building web apps. They have dealt with all the tedium, know all the requirements, and actually get out of your face when building an application. I have been developing web apps for 15 years now.
I have tried Meteor (back in the day), Remix, Nextjs, Node w/ Express, etc. Always talking about how much better they are. But in my mind web dev is a solved problem. The js stuff is mainly just developers wanking off, driven by a bunch of dollars from big companies.
Systems stuff, deployment infra, etc. is great for stuff like Rust & Go, but shoehorning into web dev makes no sense. I would love to just move on from this debate but it seems thats going to never be possible.
I agree.
Unfortunately every team I’ve worked in hasn’t seen the light and prefers FastAPI/SQLAlchemy/Pydantic (before FastAPI it was Flask).
My theory is that the initial learning curves are different: with FastAPI it’s quick and easy. You barely have to read anything. Django has a steeper learning curve. There’s a lot of reading involved. Type hints aren’t a big thing in Django, but they are in FastAPI, and the average full stack dev seems to like them.
Later on it’s totally different of course. With FastAPI you’re building it all from scratch, and it’ll be much worse than the Django solution.
Type hints are were the whole Python ecosystem is going, so using them is more integration at a deeper level than using an integrated framework, which is not relying on them.
SQLAlchemy was historically a much better ORM than Django's. It's layered architecture combined with Alembic does make a difference.
I still agree that using the integrated thing anyway is probably the right way to do it if you are working in a team. I also think Django should just adopt these components and we would not have the discussion in the first place.
As someone that used AOLServer, was in a startup doing something like Rails but in 1999 with Tcl, I don't really agree.
The Rails demo wasn't that appealing to me, other than showing the difference on how lucky one might get regarding adoption and spotlight being in the right place.
Nowadays I still don't see a value, and rather go for Spring or ASP.NET.
By the way, the founders of that Tcl based startup, went on to create OutSystems, which is one of the few successful RAD tools for Web development at enterprise scale, and Portuguese success stories in IT world.
From my experience, these frameworks are like the express lane for kicking off a project because there are no big decisions to make. But once you’re knee-deep in Rails, Django, or Laravel and need to do something off the beaten path, things can get dicey. Why? Because you didn’t write the glue code yourself, so there's a gap in understanding, not really a technical roadblock (most of the time!). My point is, if you dive into these frameworks and actually learn the guts, you'll save yourself tons of time coding by, well, reading code.
Now, do I actually do this? Absolutely not. Rewriting everything is way too much fun, and I live for the thrill of trying new things, even if it makes zero business sense.
I must say that even if it’s not a trendy stack, I find Spring Framework/Spring Boot to be the best all-around web application stack. Very easy integration with the tons of java libs you have around that can do virtually anything, a statically typed language which can help in a lot of situations (just data binding by convention via Jackson is great since forever, while it’s an afterthought in dynamically typed languages).
I've been incredibly pleased with Ktor and Kotlin, as well. JVM underneath, robust libraries, easy to use infra, using Exposed for the ORM which is mostly (genuinely) a joy.
The best thing I think Rails still has is ActiveAdmin. Everything else, I really can take or leave.
> The best thing I think Rails still has is ActiveAdmin. Everything else, I really can take or leave.
ActiveAdmin gets you off the ground very quickly, but is also extremely inflexible (and, IIRC, poorly maintained). The last time I worked on an ActiveAdmin backend we had to use all sorts of weird hacks to build the interface the way our backoffice team needed it to be.
I did write a lot of Java but never called myself a Java developer, and in my current company there are a lot of hardcore Java devs who used to swear by the Spring stack (some even liked JSF!), and a lot of them are moving things to Quarkus (https://quarkus.io/). No idea why, just an observation.
They are moving there because it's new and shiny, not because it's better.
Spring and Spring Boot are incredibly productive and give you a ton of stuff out of the box, whereas some people actually enjoy writing a lot of plumbing code as a distraction/challenge from boring business code. Those people will migrate to "lean" frameworks because it will give them the opportunity to write more low-level plumbing code.
> They are moving there because it's new and shiny, not because it's better.
I highly doubt that.
The real reason is likely more about the GraalVM, which spring hasn't supported until very recently. (And still only with caveats)
That sort of proves my point, though. Spring support for GraalVM is ongoing and will likely be quite useable and mature out of the box.
The people jumping to Quarkus or Micronaut are more eager to chase the new shiny and are willing to spend the time debugging not-yet-mature stacks.
Edit: To be clear, the reply mentions fanboyism but we are talking about the maturity of a stack. Spring has been around for 20 years and is not going anywhere. Quarkus just reached 5.
The GraalVM is significantly more performant. Calling that "chasing the new shiny" redefines the meaning of the expression, which has historically been about side-grades for unclear advantages.
Especially considering that Springs support isn't full yet, and quarkus has been around for 5yrs now.
They're both production ready stacks though, really strange to have spring fanboyism in 2024
JSF can be a great experience when coupled with the right framework like PrimeFaces.
I do not agree. Rails is absolutely great in terms of features and productivity, but will fail you elsewhere i.e. it is not the silver bullet for webdev. Do not take my opinion, look at data - https://www.youtube.com/watch?v=Qp9SOOtgmS4
If you are using Rails for anything where you are not absolutely sure of how many users or RPS you will have, you are just saving money in launch time but spending more on servers.
> you are just saving money in launch time but spending more on servers.
But... That's kind of the whole point
Shopify is built using Ruby on Rails, they successfully handle enormous traffic spikes during Black Friday sales without issues.
So I think we're good with performance.
Everything can scale if you throw enough servers at it. Of-course Shopify scales, they even spent time and money to build a JIT on top of Ruby. As a smaller company, does everyone have the time and money to spend on servers or optimising the language to this extent?
No, they only have time for features and productivity, which is, as you pointed out earlier, what rails is good at.
Smaller companies have less traffic, need less expensive servers, and have no need to spend money optimising the language. They can focus on that when they make billions of dollars, like Shopify does.
> just saving money in launch time but spending more on servers
That seems like an amazingly good trade off, even if it were true which I am not sure about.
If RPS become a problem you can probably switch to JRuby. I did exactly this 15 years ago for EUs biggest software company and it worked out quite well.
Have you seen the latest state of JRuby development or seen the posts of its development team. If you are comfortable with the idea of your main runtime being dependent on the time / finances / availability of around 5 (or less) core developers I would say you are ok with JRuby.
I came through to note that most of this applies to Django, too.
I've historically preferred RoR but with the tremendous growth of Python in the last 10+ years, Django has become a more practical choice. ML and data science devs are already familiar with Python and, with the Django docs being as excellent as they are, these folks can be productive in a very short amount of time -- should they need to be. I've seen this firsthand on multiple projects.
Also, along with the author's case for the path of least resistance, the Django framework results in fewer "decisions" (arguments) about application structure than using a less opinionated library or micro-framework.
The Django/FLOSS community is also much more active than I was expecting it to be (Rails bias, probably) and has been very pleasant to interact with.
I only wish Django had Rails-like generators and in-built data seeding (e.g. rake db:seed).
I like the rails dev experience, but it feels like they haven’t come up with nice new front end solutions that an integrated framework like nextjs has done.
One specific example is images and srcset. If you are doing a react front end anywhere in your app (not even an SPA) interfacing with the asset pipeline doesn’t have a canonical solution.
This just makes it feel behind the times, since what I always liked about rails was the “one right way” that was always reasonably sane.
So it feels like nowadays you need to trade user functional front end app things, like load time and LCP for dev experience in rails. Sad.
I disagree. Rails is fine but just a differential approach. I prefer a standalone fronted that talks to an api layer. Web Frontend for me is remix. Mobile is react native and api layer could be any language you're productive in, eg. Java,.net or javascript.
I'm working with Rails for 17 years now, still love it and still prefer it even for the frontend. It give you all the options to separate your code without the head of your files becoming a unnecessary long list of `includes` like I see in the angular app I have to work on for a client. I don't see a disadvantage in splitting logic and markup for the frontend, it allows you to test the logic independently and normally when you hunt a bug you should know whether it's in the markup or the logic. Tracking down a bug thus becomes more easy.
I've written my fair share of far too long ruby methods, 200 lines and more, but those are truly my fault. With a more granular unit test regime those can be prevented.
You know what else allows you to avoid having that long list of includes? Making everything global. I'm not sure if I see this as a benefit. Imports can take up a lot of space, yes, but they also make it explicit how everything ties together. If they're in your way, you can always have your IDE collapse them.
Rust is a language built by extremely smart people, unfortunately their focus is more on type theory and sparing few allocations than building something useful and coherent for blue collar devs like me. When I read a blog post on rust, I literally don't understand half of it, although I'm working with rust since 2020.
The reason NextJS and similar tech like SvelteKit are so popular amongst JS developers is that they alleviate the problem of Node.JS not having a great backend development experience. Building a backend in Typescript is like building it in C#, but without the advantages of a properly designed language. The experience of building a backend in Rails is miles away.
Node.JS developers are starting to realize it's not just about having the ecosystem and the tooling, it's also about the framework being a holistic solution to building out your application. That's what NextJS and SvelteKit help with, and that's what Rails revolutionized back in 2006.
> Building a backend in Typescript is like building it in C#, but without the advantages of a properly designed language.
I like typescript. In what way isn't it a "properly designed language", compared to C#?
While it is thoughtfully designed, its type system has been designed under the severe constraint that it must be retrofittable on typical JavaScript code.
Which if it was easy, instead of someone like Anders Hejlsberg leading a language design team, anyone would do it.
I didn't say it was easy. It obviously wasn't.
Your comment doesn’t advance the conversation in any way. It just restates the claim that typescript is worse in some unspecified way.
Can you give any examples of ways in which those constraints have resulted in a worse language?
> Your comment doesn’t advance the conversation in any way.
That's oddly rude. I thought it might be useful to someone (not necessarily you) to bring up the fact that TypeScript is subject to a very different pressure than most other mainstream languages. That has obviously resulted in a very different type system, e.g., one with much better support for structural typing than most mainstream languages.
> It just restates the claim that typescript is worse in some unspecified way.
I did not "restate that claim". In fact, I was careful not to claim that TypeScript is "worse" than any other language, because that's a meaningless word without more context.
> Can you give any examples of ways in which those constraints have resulted in a worse language?
Again, saying that it's "worse" or "better" without context is meaningless.
In a way where you can’t admit that you like JS, because it’s not cool.
Well it’s bolted on for a start so introduces overhead from the get go. Its type system is also severely hamstrung and complicated by JS compatibility. It doesn’t really compare to Rust, Swift, OCaml etc.
I do think it’s a huge improvement on JS though.
You say that, but its type system has some wonderful feature that those other languages lack. In what way is it hamstrung? It seems better than C# to me!
For example, C# doesn’t support parameterised enums like typescript and rust do. Once you start using parameterised enums, you seriously can’t go back. It’s a killer feature.
But even then, typescript goes further. All of these languages let me make a Color enum with red, green and blue variants. But as far as I know, only typescript will let me write a function which takes a strict subset of those variants. In typescript I can have a function that only accepts red or blue - and passing green (or something that might be green) would be a compilation error.
Typescript also lets you make another type with a superset of another type’s variants. Eg type Foo = Color | “yellow”.
In rust if I want to change a function’s signature to make one of the parameters optional, that’s a breaking api change since all existing callers need to wrap the parameter in Some(val). But in typescript, I just change the parameter’s type from T to T | null and everything works.
Again, in what way is it hamstring? I’ll grant that JavaScript doesn’t have quite the performance of C# (though modern runtimes are pretty impressive!). But typescript itself seems great.
If it comes to C# vs Typescript, I'll happily chose C#, at least for backend.
For the FE I would prefer Typescript over Javascript.
Why? I don't really understand the point of declaring a preference if there's accompanying explanation.
I wish, unfortunately in the golden age of SaaS vendors, many seem to have Vercel deals in place, so Next.js with Typescript it is.
> That's what NextJS and SvelteKit help with, and that's what Rails revolutionized back in 2006.
Are you seriously comparing "being able to execute code on the backend" with Rails? Or Django? Or Laravel?
There's no way in this world Next/Remix/etc are helping in any way to write code on the backend. Where's the support for database access? migrations? ORM? queues? scheduled jobs? validations? translations? authentication? authorization?
The only thing Next.js is helping with is pushing people towards Vercel's platform, that's it.
Great real world article. Everybody should keep the bottom line "under their pillow":
>> Interestingly, all of the things that used to annoy me about Ruby and Rails now annoy me much, much, much less. I have accepted that there is no perfect language or framework. You just have to know its strengths and weaknesses and deal with them.
A little gem of an article, thanks for posting. It's nice to see a pragmatic take on rewriting for a change. Feels like a good primer to read before considering a rewrite myself haha
Regarding rewrites, I'd love to have my code in such a shape that I could just copy over the business logic, maybe even put it into an independent library. The rest is just a user/api interface after all.
When people nag about frameworks I usually think that have their “perfect” world idea they don’t want compromise. Lots of times it is not having full understanding of the framework and why’s.
But it is much more efficient working with the framework, knowing its limitations. Just spending time really understanding tools one work with.
Writing large web applications in Rust isn't going to happen fast. Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend.
Choosing something like Java, C# or Go might not sound sexy or cool, but with get the job done as fast as Rails while running almost as fast as Rust. That choice will also generally mean less bugs and a having a project that is easy to maintain and extend.
> Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend.
With care, none of that is necessarily true. I think that's an overgeneralisation.
I've worked with many large, bug free, stable and easy to modify rails apps. I've also worked with messy rats nests rails apps, and go apps, etc.
It can be true that some languages/frameworks make it easier to get into that state, but all have a chance to make that a possibility, or other trade offs that make it difficult to build with for other reasons. With discipline you can make anything work.
I think the biggest difference for me is that when there's a rat's nest of a Rails application, refactoring it becomes the hell of type errors and writing tests that, frankly, a compiler would catch.
And with sufficiently large applications, those issues really start to spread through the whole program - or can.
addendum: I'd love to know why I'm getting downvoted here. I definitely speak from experience, here.
I guess my point was that, with discipline, it's not a foregone conclusion that a Rails app is going to be a rats nest. The lows can be pretty low for sure. But it's one of the tradeoffs for the framework and one that can be mitigated with thought and effort.
This is my experience as well. Rails makes it incredibly easy to get a web app off the ground but as it grows and adds more features and complex business logic it becomes much more difficult to maintain than a codebase with static type checking.
You can't be seriously saying using "Go" (a low level systems language) will be as productive as using Rails (a very high level framework intended for CRUD applications). Despite how much you might hate Rails, that's like saying you'll build a blog faster with C++ than with WordPress.
Go, a language with garbage collection and a compiler that does only an average job at optimizing machine code, is now considered low level?
It is as high level as C, unless you consider all non ISO extensions part of the language, in which case, any language can have similar extensions.
There are more compilers by the way.
Last I checked, C was not garbage collected.
In terms of Go or C, even Rust which is one of the only of the two used in kernel development. Migrating is in line with the principles of the CRUD methodology, whether it takes place by means of a compiler or a junior developer parsing assembly line-by-line.
Go is not a low-level systems language. Even using the more flexible modern definition of "low-level" it's not a low-level language. That's like saying OCaml is low-level; it's not even close.
Great given that OCaml seems good enough to write hypervisors and unikernels.
Go is not a low-level systems language, but it is a low-level web site builder language.
You can write large applications in Rails that run fast, have low bug counts and are not hard to maintain or extend. There are many examples in the wild.
Rails is quicker to build in than Java, C# or Go for most functionality needed in most web applications for similar skilled developers. In my experience, up to 3x quicker.
I’ve worked on large monoliths and SOAs, and worked alongside Java teams. I even introduced Go to a Rails shop because I believed what you did.
Turns out the real problems were MVC isn’t right for everything, and we weren’t name-spacing with enough rigour. Fix those in small and targeted areas, and Rails is just fine.
> Large applications written in Rails won't run fast, might be ridden with bugs and might be hard to maintain and extend.
I have never used BaseCamp, but I believe their products are well written and decent, hence with adequate care, good architecture and maintenance, it should be possible.
I'm a little confused about the comments here saying Rust is not great for web backends. I've had the opposite experience, building mostly small services like beampaint.com and probablyup.net. Maybe the complexity goes way up once you try to build a bigger app? I mean surely it does,but Rust is great at giving you confidence where you need it when you have large code bases
Right, wouldn’t the difficulty go up drastically as soon as you need more framework-territory things? Because the established frameworks have them out of the box but the Rust framework is unlikely to (due to age). Imagine going from just two of those missing things to six.
I’m the same with Django.
I’ve found that perf issues were much more often caused by the DB queries than by Django itself.
I think almost always the DB query will take the longest but: I've seen too many engineers not even do basic optimizations such as creating indexes.
Here's a list of easy/low hanging fruit optimizations that are often just forgotten: Creating indexes in the db, delegating more logic to the db than doing it in code (e.g. using pipelines in mongodb, partial indexes in postgres, etc.), turning on brotli/zstd compression for all or most requests, caching objects or requests in memory (e.g. with redis), setting appropriate cache control headers, frontend stuff such as not rendering thousands of objects as DOM nodes and instead using canvas (recently saw this in a map application).
I have seen the opposite too, a db full of indexes that grew very large and was very slow on inserts! Understanding that an index is only useful on columns that you want to search might be a start!
We recently started testing AdonisJS as a TS alternative to rails.
I'd recommend anyone who'd be interested in "Rails, but in TS" to give it a go.
It feels much more similar to rails (or Laravel) than the most popular TS stacks, and also has "batteries included" instead of leaving you to decide on every part of your stack (or trust a template from a third party).
Using Rust for a CRUD application is a terrible choice. Of course it won't work.
It's like using Rails to write a database or a DNS server. You're just trying to use the wrong tool for the job.
It's not a terrible choice. It's not necessarily wildly better than alternatives, but it's not wildly worse, either.
Among other reasons to consider it: if you want to run on a FaaS platorm or container setup, Rust has much faster cold start time and makes for smaller container sizes.
Among reasons to not consider it: if you want to iterate rapidly by editing text and near-instantly hot-reloading your code, Rust web frameworks aren't really there yet. They will be one day, but they're not yet.
> Among other reasons to consider it: if you want to run on a FaaS platorm or container setup, Rust has much faster cold start time and makes for smaller container sizes.
Faster start time maybe, but I’m not sure about smaller containers. Rust is terrible with binary sizes in my admittedly limited experience.
I just compiled and checked:
- sqlx binary: 200+ crates, 5.4Mb (after strip), 27 kb per crate on average.
- zero2prod last example: 400+ crates, 14Mb (after strip), 35 kb per crate on average.
Binary is statically linked, so Docker container is very small too.
In my experience, CRUD applications in Rust are good: they are easy to write and test. :-/
Why you think that Rust is a wrong choice for a simple or a complex CRUD application? Can you explain, please?
This:
"Have many issues at runtime? Test more. Does it turn into unmaintainable spaghetti code after a while? Only if you let it. It's typically caused by developers, not programming languages or frameworks."
Yes. I'd much rather work with developers that know how to untangle and fix spaghetti, than those that have their hands held so steady by the environment that when the spaghetti does show up they don't know how to get out of it.
And when the code becomes spaghetti, types will make it far easier to trust that the de-spaghettiing of it is safe.
This is a nice enough article considered as an experience report. It’s tempting for me to focus too much on the title (was it a rewrite in an interesting sense? no, it was like going on a five-year trip across Asia and returning to your hometown to marry your high school sweetheart[1]).
It doesn’t seem like the author learnt that much. They know Rails and Rails is good for making webapps? Makes sense.
[1] For the author. The rest of the team didn’t know Rails. And there was no one on the team that knew that rewriting parts in “blazing fast”-lang would work.
Yeah, it is maybe a bit of a clickbaity title, but I thought it was relevant enough. I tried Rewriting it in Rust and ended up not finding it worth the cost. There was some rewriting in Rails, but indeed, not very much.
I did learn that things wouldn't necessarily be any better if I were to use language/framework X instead of Y.
Edit: I guess I also learned that Rails does so much for you, so you can focus on building a good product. Just gotta make sure you use it as it wants to be used as much as possible.
It’s fascinating to me to see that nowhere in this thread, at the time of writing, is mentioned what used to be the darling of web development, a language that seduced many ruby developers to crossover: Clojure. The times have changed.
To do Clojure web development was to noodle around stitching together various libraries piecemeal, i.e. the same thing that everyone who resists proper batteries-included web frameworks does.
Those folks are now bragging about Elixir, or maybe they jumped again into Gleam now.
I think Elixir/Phoenix may be seducing more of them these days.
React plus Rails is my favorite modern combo. Development bliss.
https://github.com/shakacode/react_on_rails
Laravel with Filament is super productive also. Django used to be my goto for 15 years but the frontend infra, Livewire, and flexibility of Filament compared to django-admin are hard to beat.
A very rambling, train of thought post. Would be nice to hear factual examples of what 'plumbing' you had to do in Rust.
Not getting this one. Programmer writes app in framework he knows experiences productivity?
This article is kind of the story of my life… I launched a SaaS app written in Go in 2013 coming from Rails and I had to figure out everything on my own. Migrations, database layer, asset pipeline, deployment, validations, logging, payments and so many more things that rails just give you.
That experience has likely made you a more skilled developer, though.
You're comparing a systems oriented barebone low level programming language to a very (maybe the most) high level framework on top of a very (maybe the most) high level language.
I'm not a fan of Go, but that's not the thing to blame here. Using Go for a "CRUD" application is a terrible decision from the get go.
Go is not a low level language. It does pretend to look like C but places at the other end of abstraction spectrum, even if it doesn’t seem that way.
I’m not blaming and I fully knew what I was getting myself into. In the end it worked out and successfully launched etc. Just took me longer and had a learning curve that made me a better developer too. But had I wanted to just launch quickly from a business perspective Rails would have been the way as I already knew it. I still to this day like the simplicity and speed of Go. Like every year or two I come back to Go and try to get the dev experience for my own framework right with Rails in the back of my mind but it’s tough and more of a boilerplate than a framework.
Rust is fine.
The worst is TypeScript and Node.js.
A lot of startups are making their code bases in TypeScript. And it is an unbearable mess.
I recently consulted with a company where I rewrote their app in Rails. And now it's much simpler, much better, much more extensible, and far more enjoyable for the developers to work on it.
As a Rust dev it feels like I can't rely on the Typescript compiler at all. If you don't spell everything out for it, it might silently fail to infer the type of a variable and suddenly the function returns a number array instead of a string and the compiler will be just fine with it. Not to mention runtime still has all the problems of JS.
>[...] suddenly the function returns a number array instead of a string and the compiler will be just fine with it.
The type checker is quite forgiving, but that does not sound like something it would just be fine with?
The TS type system is not sound which has obvious tradeoffs. I prefer it over Rust for most things because Rust feels like a Comic-book-guy type person looking over my shoulder going "Akshually, you didn't tell me what the lifetime of this string is", even if it is trivially obvious. I acknowledge that there are situations where that is very valuable but in my opinion it's not generally superior.
Are there persistent ways in which you think Typescript codebases end up a mess?
Developers have to invent too much themselves vs Rails? Something deeper?
Somewhere, DHH is reading this and smiling…
I want to try Rails but I can't downgrade away from static typing for my personal projects. I typically want to spin them out quickly and not worry about writing tests: static typing adds way too much value in that scenario.
I looked into Ruby's static typing attempts but the picture painted was grim.
Sadly, that is the reality of Ruby, no excuses. Introducing static typing to Ruby is a huge task considering the way the language is designed.
The attempts you've seen is probably Sorbet (sorbet-runtime) and RBS. In my opinion, RBS would be an option for me if they didn't force me to work in a separate file just for type declarations.
There is one gem that is interesting, it reminds me a lot of jsdoc. It's called rbs-inline https://rubygems.org/gems/rbs-inline
There's this weird conceit that Ruby On Rails somehow has a monopoly on developer experience, that Ruby On Rails gives developers pleasure that is unique and uncopyable - a unique and utterly amazing and incomprehensibly awesome developer experience that no other language or framework can replicate.
Rails developers smugly assert that Ruby on Rails is more productive than anything else out there.
I call BS on the "Ruby On Rails is the very best by far" conceit.
Ruby On Rails has a monopoly only on the perception that its developer experience and productivity is off the charts.
Ruby On Rails is just another language and framework. There's literally nothing that makes it different or particularly special compared to anything else.
Developers everywhere with Python or nodejs or TypeScript or C# or Golang have a developer experience that is just as great, without the high handed conceit that what they are doing is amazingly better than anything else.
SEGA used to have an advert, "To be this good takes AGES". Maybe Rails doesn't have a monopoly on having 20 years of continuous development refining it, but it's not the norm.
Imagine if the author had tried Phoenix and Elixir with its amazing OTP foundation…
the elixir ecosystem doesn't have the "library for anything you could possibly need" benefit that you find with rails (and probably django too)
As an elixir dev I am wondering what exactly you’re missing?
most recently, maximum matching over a graph (edmond's blossom algorithm)
> maximum matching over a graph (edmond's blossom algorithm)
Ruby/Rails has this?
That actually sounds like a perfect use case for a Rust NIF in Elixir, since graph matching can be a performance issue
Please don’t.
You pay 100x for each line of code and get nothing in return over ASP.NET Core or Vert.X. Pick any fast compiled language you like, don’t contribute to global warming.
“Don’t contribute to global warming” is the silliest argument for perf bc you can use it to dismiss basically any human leisure activity. Why is it okay to use a computer to play video games but not make the perf tradeoff with Ruby?
Because there is no trade off. Rails does not offer anything over picking Kotlin/C#/F# or even Go offerings. The “productivity” is a little excuse used to hand wave away the criticism of absolutely unacceptable state of Ruby performance in the year of 2024 and all the other problems that it has.
What do you mean? Rails seems to come with authentication, session management, cookie management, an ORM, extensive logging capabilities and a bunch of other things. Go and Kotlin are languages, not frameworks, and they certainly don't include these things. So what are you comparing exactly?
My initial comment lists two great options that make choosing Rails an unconditionally short-sighted decision.
ASP.NET - maybe, but you’ve got to be kidding if you suggest Vert.x to be a replacement for RoR. They operate on completely different levels of abstraction (even ignoring nightmare of Reactive code you have to write using Vert.x).
Not a nightmare at all, if you know what you’re doing. There’s a learning curve indeed, I’ll give you that.
Ruby really isn't that slow -- even so most of its "performance" problems are due to idling waiting for I/O not actual code.
If you care about power consumption of computing you need to be looking at current AI and crypto currencies consumption like Bitcoin…
The whole article is about how there is a tradeoff, sorry they didn’t investigate your preferred technology but you can’t expect them to try forever. Even if they had tho, are those really “batteries included” offerings like Rails?
You can argue that game devs also have moral obligation to mitigate impact of their games by better optimizing them.
Okay but where does it stop? Surely any amount of energy wasted on entertainment is wrong.
Why is it okay to waste energy for entertainment but not waste energy for development experience and efficiency?
"I couldn't horseshoe a hard systems language to replace a web framework for a CRUD app written with soft language, so I had to go back"
Rails is very good until you need to go off rails. Even in that case rewrites must be partial and not to aim to fully replace the original. Most of the time rewrites are a waste of time. This article could be true if you s/Rust/Ruby and tell the story in the opposite direction.
Didn't we make this mistake and learn from it in 2005? I guess not.
Ruby, and Rails, was an awful idea then and it's an awful idea now. Even in-browser stuff is moving to typescript to get away from having to write unit tests for basic type errors.
But sure, let's dig up this failure and try it again