12 ms·

Rewrite It in Rails

271 points by WuxiFingerHold 2y ago

WuxiFingerHold 2y ago
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.
- bubblyworld 2y ago
  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
  - TomK32 2y ago
    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.
  - probablybetter 2y ago
    i saw that... (gem, ruby... hahhaha)
- ozim 2y ago
  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.
- dajonker 2y ago
  Yes this was indeed the most important thing for me to realize. I am now much happier, not constantly thinking "if only I had Rust enums!"
- karmakaze 2y ago
  For context that came after trying this: > Meanwhile, I started building "version 2" of the application. I chose Rust as the language for the backend and SvelteKit for the frontend. Since it started out as Rails in v1, the post is to beware abandoning a framework that's working for you.
  - dajonker 2y ago
    Also try other languages for yourself and see if they are indeed as good as you think they might be. Or you might never realize that the grass isn't necessarily always greener on the other side. Unfortunately not everyone will have time to do that for longer than a couple of hours or days.
TomK32 2y ago
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.
- Etheryte 2y ago
  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.
  - axelthegerman 2y ago
    > but they also make it explicit how everything ties together So does the autoloader used in Rails, it's called convention over configuration. There are only very few places it will look for the code (and in production everything gets preloaded too) So unless you want your class User actually in iMeanThisUser.ext or ../../../a/random/path/that/makes/no/sense/user.ext you shouldn't need explicit configuration
0xblinq 2y ago
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.
- JoshTriplett 2y ago
  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.
  - elcritch 2y ago
    > 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.
    - oneshtein 2y ago
      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.
      - elcritch 2y ago
        Exactly, 14Mb for a simple API server like zero2prod is rather large. That's with stripping, if you want the ability to debug and get pretty panics it'll be even larger. You can download a pre-compiled sqlite tools package includes four binary CLI tools in only 6.5 MB vs that one sqlx binary which is 5.4 MB. Of course they're not the same, but the general trend I've seen is that Rust is as large or often larger than bloated C++ projects. For example I worked with Rust on a Yocto project where you can't use Rust's stripping config because it breaks (broke?) the hashing Yocto does. A very small IoT API project ended up being 50+ MBs. It was larger than the rest of the entire Linux system. I've written IoT projects of similar complexity in Go and Nim which come in under 3-4MB with full debugging no stripping needed.
tinco 2y ago
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.
- josephg 2y ago
  > 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#?
  - creata 2y ago
    While it is thoughtfully designed, its type system has been designed under the severe constraint that it must be retrofittable on typical JavaScript code.
    - pjmlp 2y ago
      Which if it was easy, instead of someone like Anders Hejlsberg leading a language design team, anyone would do it.
      - creata 2y ago
        I didn't say it was easy. It obviously wasn't.
    - josephg 2y ago
      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?
michaelteter 2y ago
Imagine if the author had tried Phoenix and Elixir with its amazing OTP foundation…
- zem 2y ago
  the elixir ecosystem doesn't have the "library for anything you could possibly need" benefit that you find with rails (and probably django too)
  - flymaipie 2y ago
    As an elixir dev I am wondering what exactly you’re missing?
    - zem 2y ago
      most recently, maximum matching over a graph (edmond's blossom algorithm)
      - flymaipie 2y ago
        That actually sounds like a perfect use case for a Rust NIF in Elixir, since graph matching can be a performance issue
      - biorach 2y ago
        > maximum matching over a graph (edmond's blossom algorithm) Ruby/Rails has this?
        zem 2y ago
        ruby does indeed, as do python and javascript. here's the ruby library: https://github.com/jaredbeck/graph_matching https://github.com/jaredbeck/graph_matching
  - josefrichter 2y ago
    This claim is greatly exaggerated
physicsguy 2y ago
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.
- sureglymop 2y ago
  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).
  - jimnotgym 2y ago
    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!
  - VMtest 2y ago
    creating indexes will lock the tables if not mistaken, the problem about database is that many of us just don't study enough to make sense out of it
    - t-writescode 2y ago
      In PostgreSQL you can create indexes concurrently, so the database doesn't have to go down to create a new index: https://www.postgresql.org/docs/current/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY https://www.postgresql.org/docs/current/sql-createindex.html...
keybored 2y ago
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.
- dajonker 2y ago
  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.
hit8run 2y ago
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.
- 0xblinq 2y ago
  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.
  - neonsunset 2y ago
    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.
  - hit8run 2y ago
    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.
- Rzor 2y ago
  That experience has likely made you a more skilled developer, though.
  - juliogreff 2y ago
    I'm going through the same path right now, building my own product, and while I do indeed feel like it taught me tons, I don't want lessons, I want to get a business off the ground!
jeppester 2y ago
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).
- hanifc 2y ago
  I've been curious about AdonisJS, and I think I'll give it a try thanks to your comment. Recently, I've been fascinated by the "batteries included" back end frameworks of Rails, Laravel, and Django, but I've written TypeScript for pretty much my entire career, and it's just easier to keep it that way than to switch now. What are your thoughts so far in your testing? Could you compare it to any of those other frameworks I mentioned?
  - jeppester 2y ago
    I cannot compare it to Django and Laravel since I haven't used them for a few years. Rails is definitely more mature. It has a larger ecosystem and much more documentation. If you don't see any benefit from having types and sharing the programming language between the backend and frontend, then you are probably better off with rails. That being said AdonisJS has been working out surprisingly well thus far. I've found the documentation to cover pretty much anything we'd usually want an app to do, which is refreshing in the world of TS. You are also not locked in any way. While you can use the in-house ORM, validation library etc., it's easy to use something else if you prefer that. There are a few more rough edges than what you'd be used to from Rails, but nothing big so far and the source code is easy enough to get around, which I wouldn't say is always the case with rails. There's also a discord channel that seems fairly active and helpful.
- gejose 2y ago
  Been meaning to try out AdonisJS and this is good to hear! For a recent personal project I went with NestJS but soon after discovered Adonis. I've actually been considering switching.
DeathArrow 2y ago
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.
- 0xblinq 2y ago
  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.
  - 59nadir 2y ago
    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.
    - yxhuvud 2y ago
      Go is not a low-level systems language, but it is a low-level web site builder language.
    - pjmlp 2y ago
      Great given that OCaml seems good enough to write hypervisors and unikernels.
  - jb1991 2y ago
    Go, a language with garbage collection and a compiler that does only an average job at optimizing machine code, is now considered low level?
    - deleted 2y ago
neonsunset 2y ago
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.
- bowsamic 2y ago
  “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?
  - neonsunset 2y ago
    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.
    - deleted 2y ago
      [deleted]
    - bowsamic 2y ago
      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?
      - deleted 2y ago
        [deleted]
    - WA 2y ago
      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?
BoorishBears 2y ago
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.
- Alifatisk 2y ago
  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 https://rubygems.org/gems/rbs-inline
  - xiphias2 2y ago
    It's not really sad. Optional static typing has advantages and disadvantages and there are enough dynamic programming languages that have it (JS, Python for example). I think the problem with static typing is that it changes the whole ecosystem too much to be considered just optional, even if it's backwards compatible (like in Python). Just as an example I'm using lambdas in fasthtml in Python that don't allow type specifications for adding routes and fasthtml keeps on spitting out warnings that I didn't specify the type and doesn't handle variables in lambda functions correctly.
    - Alifatisk 2y ago
      > Just as an example I'm using lambdas in fasthtml in Python that don't allow type specifications for adding routes and fasthtml keeps on spitting out warnings that I didn't specify the type and doesn't handle variables in lambda functions correctly. That's a very interesting yet valid downside I didn't think of
  - chucke 2y ago
    FYI rbs-inline is maintained by the rbs creator, and will eventually be merged into mainline, once the inline syntax alternatives are set in stone. All to address the main complaint you mentioned above.
nbittich 2y ago
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.
- Expurple 2y ago
  Could you share your examples of incoherence in Rust? I actually find it a small, well-designed and very coherent language. At least, when compared to huge mainstream languages. E.g., traits cover the use cases of both "abstract classes" and "concepts" in C++, or both "abstract classes" and "protocols" in Python. And there are no inconsistencies regarding using exceptions or returning errors by value (panics exist, but they are used as assertions). There's no separate ternary operator, which is redundant when you have an if-else expression.
  - nbittich 2y ago
    Async vs non async code. It's basically two different languages imho. generics are also a big pain to work with, specially along with lifetimes. I have fun working with rust now that I am good enough at it, but I kept my objectivity in the process of learning it.
  - hu3 2y ago
    > Could you share your examples of incoherence in Rust? just a nit. I think they used a narrow definition of coherent, for blue collars, which in web often imply mundane CRUD and agency apps. I wouldn't expand the discussion to a brother definition about a general incoherency in the language. And certainty wouldn't bring comparisons to C++ when replying to their message.
    - timkq 2y ago
      I guess by "blue collar devs" (as you said, mundane CRUD etc.) they mean devs that will quickly get replaced by AI.
  - 2y ago
smrtinsert 2y ago
Not getting this one. Programmer writes app in framework he knows experiences productivity?
ilrwbwrkhv 2y ago
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.
- duggan 2y ago
  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?
  - ilrwbwrkhv 2y ago
    There are many different ways how they make the code bases a mess but one very common way that I can pick out is a lot of indirection that is a lot of functions wrapping other functions which wrap other functions and so on where to change even one thing you need to visit and touch 40 different files.
- alpaca128 2y ago
  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.
  - kristiandupont 2y ago
    >[...] 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.
pech0rin 2y ago
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.
- alanfranz 2y ago
  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).
  - t-writescode 2y ago
    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.
    - Tainnor 2y ago
      > 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.
ridruejo 2y ago
Somewhere, DHH is reading this and smiling…
oldpersonintx 2y ago
[dead]
steve_gh 2y ago
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."
- t-writescode 2y ago
  And when the code becomes spaghetti, types will make it far easier to trust that the de-spaghettiing of it is safe.
- yxhuvud 2y ago
  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.
  - sealeck 2y ago
    I'd rather use a tool that has footguns X,Y as opposed to one without them so that when (separate) footgun Z arises in both languages the developers are more used to handling lots and lots of bugs?
simonpantzare 2y ago
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.
block_dagger 2y ago
React plus Rails is my favorite modern combo. Development bliss. https://github.com/shakacode/react_on_rails https://github.com/shakacode/react_on_rails
jb1991 2y ago
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.
- duggan 2y ago
  I think Elixir/Phoenix may be seducing more of them these days.
- frou_dh 2y ago
  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.
- pjmlp 2y ago
  Those folks are now bragging about Elixir, or maybe they jumped again into Gleam now.
crabsand 2y ago
"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.
chikere232 2y ago
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
thdhhghgbhy 2y ago
[flagged]
andrewstuart 2y ago
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.
- frou_dh 2y ago
  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 that's certainly not the norm.
  - deleted 2y ago
    [deleted]
lionkor 2y ago
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
- keybored 2y ago
  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.
deleted 2y ago
[deleted]
oftenwrong 2y ago
I once worked for a startup that used Rails for building their web app. I would say around 50% of all development was in Rails. For things that demanded more performance or correctness on complex tasks, there were some Java services and some Postgres sprocs. Our user-friendly and featureful website was a big part of our appeal. A lot of the non-Rails functionality was the unseen "secret sauce". I think this approach worked well. Most of what you need for a web app is commodity functionality. Correctness is not even particularly important in many cases. The Rails ecosystem has a lot of useful tools that make it easy. For example, there are multiple options for automatically adding a comprehensive admin panel. This let our non-technical admins manually accomplish CRUD tasks in the web app's domain. This allowed us to avoid overengineering. We could implement something that covered 80% of cases, and manually handle any edge cases or things that happened infrequently. An example is locking user accounts when a person left a customer's company; they could just email us and an admin would manually go in and check the "locked" box for the user. This allowed us to move very fast on new web app features, and focus on other aspects of the system. There were downsides, of course. One of the big pain points was upgrading Rails itself, and dealing with dependency hell at times with various libraries. You also have to know many things about how Rails works, which involves a lot of quasi-mysterious and implicitly-performed things. For example, I recall frequently coming across function calls, and then I would look for the function definition, only to find that it was a function that doesn't exist in the code and was generated at runtime by Rails.
- dajonker 2y ago
  The downside of using more than one programming language (not counting javascript) is that it makes everything more complex. Development, testing, deployment, issue tracking, etc. Plus it forces people to either specialize in one part of the application or learn two things in depth.
samjbobb 2y ago
This was a great read. Thanks to the author for the vulnerability. In this thread and others, HN does a lot of talking about the fixed properties of these languages and frameworks. Something I don’t see much is: choose the tool that you and your team are most familiar with. It’s relatively easy to learn a new language, but it takes a long time to learn an ecosystem. Learning that ecosystem takes time away from focusing on your customer. I recently started a new web app and tried to use Django because of the batteries-included framework “should” have been the right tool for the job. But I haven’t used Django in 15 years and it was slow going. After a few weeks of slow going, I rewrote the whole thing in Typescript in a week. Not because of any general argument that TS is better, but because it’s the ecosystem I know well. Not by choice, but as a function of the jobs I’ve had. I’d like to suggest that it’s okay to choose the tool you’re most familiar with, because you’ll move faster, write better code, and frankly web apps can be written in any of these languages.
pmdr 2y ago
Rewrite it in any framework that _doesn't_ make you dependent on platforms waiting to milk you dry when usage takes off.
yburkov 2y ago
we are not in 2010, why use rail? There are a lot of alternatives - java (spring) - go - node. But using rust for it is not far from c++ by craziness. So you are jumping from one strange solution to another…
- oliyoung 2y ago
  Because Rails solves problems the others don't. Also, 1. Spring outdates Rails (2002 v 2007) 2. Go is a language, Rails is a platform, Ruby is the language. Ruby and Go solve for different problems, Go doesn't have a singular web application framework to compare well to Rails 3. Node is a runtime, not a language or a platform. There's no direct comparison there.
jairojair 2y ago
Boring tech is great!
oliyoung 2y ago
The keys here for me... > After probably a good year of writing Rust and Svelte, it dawned on me that our users didn't benefit from any of this. > With days and often weeks on end being spent on adding absolutely no direct value > these last weeks I've felt very productive again, building new features, improving existing ones, updating the UI, fixing stupid bugs. I also really enjoy working more closely with my colleagues who use the application all day, every day and figuring out how I can make the product better for them. Rails is GREAT at solving PRODUCT problems very quickly and very effectively. In the right place there is nothing better at building _products_ or making engineers incredibly productive. It's not the only tool in the toolbox, but it's always been one of the best to solve early applications and proofs of concept
m11a 2y ago
I much prefer Rails to say Django, but I wish decent typechecking were possible in Ruby. All the options I’m aware of (Sorbet, header files, etc) are all so inferior to Python’s typing syntax that I feel like this alone makes me not want to use Ruby/Rails for web projects these days. I think decent type checking can fix many of the usual bugs people encounter, but the syntax for types at least needs to be decent.

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.

bubblyworld 2y ago
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
- TomK32 2y ago
  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.
- probablybetter 2y ago
  i saw that... (gem, ruby... hahhaha)
ozim 2y ago
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.
dajonker 2y ago
Yes this was indeed the most important thing for me to realize. I am now much happier, not constantly thinking "if only I had Rust enums!"
karmakaze 2y ago
For context that came after trying this: > Meanwhile, I started building "version 2" of the application. I chose Rust as the language for the backend and SvelteKit for the frontend. Since it started out as Rails in v1, the post is to beware abandoning a framework that's working for you.
- dajonker 2y ago
  Also try other languages for yourself and see if they are indeed as good as you think they might be. Or you might never realize that the grass isn't necessarily always greener on the other side. Unfortunately not everyone will have time to do that for longer than a couple of hours or days.

TomK32 2y ago

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.

Etheryte 2y ago
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.
- axelthegerman 2y ago
  > but they also make it explicit how everything ties together So does the autoloader used in Rails, it's called convention over configuration. There are only very few places it will look for the code (and in production everything gets preloaded too) So unless you want your class User actually in iMeanThisUser.ext or ../../../a/random/path/that/makes/no/sense/user.ext you shouldn't need explicit configuration

0xblinq 2y ago

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.

JoshTriplett 2y ago
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.
- elcritch 2y ago
  > 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.
  - oneshtein 2y ago
    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.
    - elcritch 2y ago
      Exactly, 14Mb for a simple API server like zero2prod is rather large. That's with stripping, if you want the ability to debug and get pretty panics it'll be even larger. You can download a pre-compiled sqlite tools package includes four binary CLI tools in only 6.5 MB vs that one sqlx binary which is 5.4 MB. Of course they're not the same, but the general trend I've seen is that Rust is as large or often larger than bloated C++ projects. For example I worked with Rust on a Yocto project where you can't use Rust's stripping config because it breaks (broke?) the hashing Yocto does. A very small IoT API project ended up being 50+ MBs. It was larger than the rest of the entire Linux system. I've written IoT projects of similar complexity in Go and Nim which come in under 3-4MB with full debugging no stripping needed.

tinco 2y ago

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.

josephg 2y ago
> 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#?
- creata 2y ago
  While it is thoughtfully designed, its type system has been designed under the severe constraint that it must be retrofittable on typical JavaScript code.
  - pjmlp 2y ago
    Which if it was easy, instead of someone like Anders Hejlsberg leading a language design team, anyone would do it.
    - creata 2y ago
      I didn't say it was easy. It obviously wasn't.
  - josephg 2y ago
    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?

michaelteter 2y ago

Imagine if the author had tried Phoenix and Elixir with its amazing OTP foundation…

zem 2y ago
the elixir ecosystem doesn't have the "library for anything you could possibly need" benefit that you find with rails (and probably django too)
- flymaipie 2y ago
  As an elixir dev I am wondering what exactly you’re missing?
  - zem 2y ago
    most recently, maximum matching over a graph (edmond's blossom algorithm)
    - flymaipie 2y ago
      That actually sounds like a perfect use case for a Rust NIF in Elixir, since graph matching can be a performance issue
    - biorach 2y ago
      > maximum matching over a graph (edmond's blossom algorithm) Ruby/Rails has this?
      - zem 2y ago
        ruby does indeed, as do python and javascript. here's the ruby library: https://github.com/jaredbeck/graph_matching https://github.com/jaredbeck/graph_matching
- josefrichter 2y ago
  This claim is greatly exaggerated

physicsguy 2y ago

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.

sureglymop 2y ago
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).
- jimnotgym 2y ago
  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!
- VMtest 2y ago
  creating indexes will lock the tables if not mistaken, the problem about database is that many of us just don't study enough to make sense out of it
  - t-writescode 2y ago
    In PostgreSQL you can create indexes concurrently, so the database doesn't have to go down to create a new index: https://www.postgresql.org/docs/current/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY https://www.postgresql.org/docs/current/sql-createindex.html...

keybored 2y ago

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.

dajonker 2y ago
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.

hit8run 2y ago

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.

0xblinq 2y ago
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.
- neonsunset 2y ago
  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.
- hit8run 2y ago
  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.
Rzor 2y ago
That experience has likely made you a more skilled developer, though.
- juliogreff 2y ago
  I'm going through the same path right now, building my own product, and while I do indeed feel like it taught me tons, I don't want lessons, I want to get a business off the ground!

jeppester 2y ago

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

hanifc 2y ago
I've been curious about AdonisJS, and I think I'll give it a try thanks to your comment. Recently, I've been fascinated by the "batteries included" back end frameworks of Rails, Laravel, and Django, but I've written TypeScript for pretty much my entire career, and it's just easier to keep it that way than to switch now. What are your thoughts so far in your testing? Could you compare it to any of those other frameworks I mentioned?
- jeppester 2y ago
  I cannot compare it to Django and Laravel since I haven't used them for a few years. Rails is definitely more mature. It has a larger ecosystem and much more documentation. If you don't see any benefit from having types and sharing the programming language between the backend and frontend, then you are probably better off with rails. That being said AdonisJS has been working out surprisingly well thus far. I've found the documentation to cover pretty much anything we'd usually want an app to do, which is refreshing in the world of TS. You are also not locked in any way. While you can use the in-house ORM, validation library etc., it's easy to use something else if you prefer that. There are a few more rough edges than what you'd be used to from Rails, but nothing big so far and the source code is easy enough to get around, which I wouldn't say is always the case with rails. There's also a discord channel that seems fairly active and helpful.
gejose 2y ago
Been meaning to try out AdonisJS and this is good to hear! For a recent personal project I went with NestJS but soon after discovered Adonis. I've actually been considering switching.

DeathArrow 2y ago

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.

0xblinq 2y ago
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.
- 59nadir 2y ago
  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.
  - yxhuvud 2y ago
    Go is not a low-level systems language, but it is a low-level web site builder language.
  - pjmlp 2y ago
    Great given that OCaml seems good enough to write hypervisors and unikernels.
- jb1991 2y ago
  Go, a language with garbage collection and a compiler that does only an average job at optimizing machine code, is now considered low level?
  - deleted 2y ago

neonsunset 2y ago

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.

bowsamic 2y ago
“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?
- neonsunset 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - bowsamic 2y ago
    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?
    - deleted 2y ago
      [deleted]
  - WA 2y ago
    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?

BoorishBears 2y ago

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.

Alifatisk 2y ago
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 https://rubygems.org/gems/rbs-inline
- xiphias2 2y ago
  It's not really sad. Optional static typing has advantages and disadvantages and there are enough dynamic programming languages that have it (JS, Python for example). I think the problem with static typing is that it changes the whole ecosystem too much to be considered just optional, even if it's backwards compatible (like in Python). Just as an example I'm using lambdas in fasthtml in Python that don't allow type specifications for adding routes and fasthtml keeps on spitting out warnings that I didn't specify the type and doesn't handle variables in lambda functions correctly.
  - Alifatisk 2y ago
    > Just as an example I'm using lambdas in fasthtml in Python that don't allow type specifications for adding routes and fasthtml keeps on spitting out warnings that I didn't specify the type and doesn't handle variables in lambda functions correctly. That's a very interesting yet valid downside I didn't think of
- chucke 2y ago
  FYI rbs-inline is maintained by the rbs creator, and will eventually be merged into mainline, once the inline syntax alternatives are set in stone. All to address the main complaint you mentioned above.

nbittich 2y ago

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.

Expurple 2y ago
Could you share your examples of incoherence in Rust? I actually find it a small, well-designed and very coherent language. At least, when compared to huge mainstream languages. E.g., traits cover the use cases of both "abstract classes" and "concepts" in C++, or both "abstract classes" and "protocols" in Python. And there are no inconsistencies regarding using exceptions or returning errors by value (panics exist, but they are used as assertions). There's no separate ternary operator, which is redundant when you have an if-else expression.
- nbittich 2y ago
  Async vs non async code. It's basically two different languages imho. generics are also a big pain to work with, specially along with lifetimes. I have fun working with rust now that I am good enough at it, but I kept my objectivity in the process of learning it.
- hu3 2y ago
  > Could you share your examples of incoherence in Rust? just a nit. I think they used a narrow definition of coherent, for blue collars, which in web often imply mundane CRUD and agency apps. I wouldn't expand the discussion to a brother definition about a general incoherency in the language. And certainty wouldn't bring comparisons to C++ when replying to their message.
  - timkq 2y ago
    I guess by "blue collar devs" (as you said, mundane CRUD etc.) they mean devs that will quickly get replaced by AI.
- 2y ago

smrtinsert 2y ago

Not getting this one. Programmer writes app in framework he knows experiences productivity?

ilrwbwrkhv 2y ago

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.

duggan 2y ago
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?
- ilrwbwrkhv 2y ago
  There are many different ways how they make the code bases a mess but one very common way that I can pick out is a lot of indirection that is a lot of functions wrapping other functions which wrap other functions and so on where to change even one thing you need to visit and touch 40 different files.
alpaca128 2y ago
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.
- kristiandupont 2y ago
  >[...] 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.

pech0rin 2y ago

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.

alanfranz 2y ago
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).
- t-writescode 2y ago
  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.
  - Tainnor 2y ago
    > 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.

ridruejo 2y ago

Somewhere, DHH is reading this and smiling…

oldpersonintx 2y ago

[dead]

steve_gh 2y ago

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

t-writescode 2y ago
And when the code becomes spaghetti, types will make it far easier to trust that the de-spaghettiing of it is safe.
yxhuvud 2y ago
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.
- sealeck 2y ago
  I'd rather use a tool that has footguns X,Y as opposed to one without them so that when (separate) footgun Z arises in both languages the developers are more used to handling lots and lots of bugs?

simonpantzare 2y ago

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.

block_dagger 2y ago

React plus Rails is my favorite modern combo. Development bliss. https://github.com/shakacode/react_on_rails https://github.com/shakacode/react_on_rails

jb1991 2y ago

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.

duggan 2y ago
I think Elixir/Phoenix may be seducing more of them these days.
frou_dh 2y ago
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.
pjmlp 2y ago
Those folks are now bragging about Elixir, or maybe they jumped again into Gleam now.

crabsand 2y ago

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

chikere232 2y ago

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

thdhhghgbhy 2y ago

[flagged]

andrewstuart 2y ago

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.

frou_dh 2y ago
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 that's certainly not the norm.
- deleted 2y ago
  [deleted]

lionkor 2y ago

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

keybored 2y ago
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.

deleted 2y ago

[deleted]

oftenwrong 2y ago

I once worked for a startup that used Rails for building their web app. I would say around 50% of all development was in Rails. For things that demanded more performance or correctness on complex tasks, there were some Java services and some Postgres sprocs. Our user-friendly and featureful website was a big part of our appeal. A lot of the non-Rails functionality was the unseen "secret sauce". I think this approach worked well. Most of what you need for a web app is commodity functionality. Correctness is not even particularly important in many cases. The Rails ecosystem has a lot of useful tools that make it easy. For example, there are multiple options for automatically adding a comprehensive admin panel. This let our non-technical admins manually accomplish CRUD tasks in the web app's domain. This allowed us to avoid overengineering. We could implement something that covered 80% of cases, and manually handle any edge cases or things that happened infrequently. An example is locking user accounts when a person left a customer's company; they could just email us and an admin would manually go in and check the "locked" box for the user. This allowed us to move very fast on new web app features, and focus on other aspects of the system. There were downsides, of course. One of the big pain points was upgrading Rails itself, and dealing with dependency hell at times with various libraries. You also have to know many things about how Rails works, which involves a lot of quasi-mysterious and implicitly-performed things. For example, I recall frequently coming across function calls, and then I would look for the function definition, only to find that it was a function that doesn't exist in the code and was generated at runtime by Rails.

dajonker 2y ago
The downside of using more than one programming language (not counting javascript) is that it makes everything more complex. Development, testing, deployment, issue tracking, etc. Plus it forces people to either specialize in one part of the application or learn two things in depth.

samjbobb 2y ago

This was a great read. Thanks to the author for the vulnerability. In this thread and others, HN does a lot of talking about the fixed properties of these languages and frameworks. Something I don’t see much is: choose the tool that you and your team are most familiar with. It’s relatively easy to learn a new language, but it takes a long time to learn an ecosystem. Learning that ecosystem takes time away from focusing on your customer. I recently started a new web app and tried to use Django because of the batteries-included framework “should” have been the right tool for the job. But I haven’t used Django in 15 years and it was slow going. After a few weeks of slow going, I rewrote the whole thing in Typescript in a week. Not because of any general argument that TS is better, but because it’s the ecosystem I know well. Not by choice, but as a function of the jobs I’ve had. I’d like to suggest that it’s okay to choose the tool you’re most familiar with, because you’ll move faster, write better code, and frankly web apps can be written in any of these languages.

pmdr 2y ago

Rewrite it in any framework that _doesn't_ make you dependent on platforms waiting to milk you dry when usage takes off.

yburkov 2y ago

we are not in 2010, why use rail? There are a lot of alternatives - java (spring) - go - node. But using rust for it is not far from c++ by craziness. So you are jumping from one strange solution to another…

oliyoung 2y ago
Because Rails solves problems the others don't. Also, 1. Spring outdates Rails (2002 v 2007) 2. Go is a language, Rails is a platform, Ruby is the language. Ruby and Go solve for different problems, Go doesn't have a singular web application framework to compare well to Rails 3. Node is a runtime, not a language or a platform. There's no direct comparison there.

jairojair 2y ago

Boring tech is great!

oliyoung 2y ago

The keys here for me... > After probably a good year of writing Rust and Svelte, it dawned on me that our users didn't benefit from any of this. > With days and often weeks on end being spent on adding absolutely no direct value > these last weeks I've felt very productive again, building new features, improving existing ones, updating the UI, fixing stupid bugs. I also really enjoy working more closely with my colleagues who use the application all day, every day and figuring out how I can make the product better for them. Rails is GREAT at solving PRODUCT problems very quickly and very effectively. In the right place there is nothing better at building _products_ or making engineers incredibly productive. It's not the only tool in the toolbox, but it's always been one of the best to solve early applications and proofs of concept

m11a 2y ago

I much prefer Rails to say Django, but I wish decent typechecking were possible in Ruby. All the options I’m aware of (Sorbet, header files, etc) are all so inferior to Python’s typing syntax that I feel like this alone makes me not want to use Ruby/Rails for web projects these days. I think decent type checking can fix many of the usual bugs people encounter, but the syntax for types at least needs to be decent.