Rails for everything
literallythevoid.com
literallythevoid.com
Grails Framework (Spring Framework more like Rails) integrates errors directly into the domain model, so if you have a domain class Person, it was extended with person.errors property.
What value does "not coupling" give you, when you end up copy pasting the attributes from one object to another anyway?
It does require the discipline to actually _do_ the 'replace it' part when you reach that point and the results of failing to do that are ... not pleasant ... but that doesn't mean it's _always_ the wrong choice, especially when getting started.
IMO this is good coupling since it's very loose, trivially changed and eliminated boilerplate code that's just noise. Of course, as always, it depends on a number of circumstances what trade-off is best for you, your team, the specific problem, etc
The problem is, Go community has never really filled that gap. I love Go, but the whole "Go doesn’t need a Rails or Django" mindset is part of why it hasn’t taken off in this space. Building networking tools and CLIs in Go is great, but when it comes to quickly building a full-stack web app, I still reach for Rails or Django. So this whole "X is dead" doesn't apply to Rails at all.
Go is in an awkward spot—it’s not dethroning Python because it’s not as expressive, academics hate it, and it’s not as fast as Zig or Rust to appeal to systems programmers. So it only makes sense to target the web services section dominated by Django and RoR.
[^1]: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
A much nicer library for dealing with Kubernetes is the kube crate [1] for Rust. The worst aspect of it is the dependency discipline, though that is no worse than the official Go client.
I’m really having fun with Go these days, though
That said, Python is great, and beginners love it. For algorithms and prototyping, I still prefer it. But for writing servers, Go’s stdlib lets me spin up a production-ready, concurrent server using just the basics. What Go lacks, though, is something like Django, which it could really benefit from.
Define good, and for what applications? I'm having a very hard time imagining that go's standard library is anything like as comprehensive as python's.
I’ve found the Go standard library to not only be very complete, but also to contain far fewer sharp edges and dead batteries than that of Python for every use case I’ve tried.
I would offer that Erlang did a good job of capturing the [concurrency?] space, though some of the tooling is showing its age.
It's therefore interesting to see Elixir straddle the divide between Erlang and Ruby.
I'm still Rails all day, but I've never stopped thinking Elixir is cool.
1. The feature set is just far weaker. If an LSP implementation and the client both hit 100% coverage, then you might end up having the same refactoring, code generation, follow definition/load docs/infer typing support. But of course the Elixir LSP matrix shows that basically none of the LSPs offer a complete feature set and you basically get to pick which features are missing. What about debugger support?
2. This could be viewed in some ways as a recapitulation of point one, but I actually appreciate the Integrated in Integrated Development Environment. I very much dislike when adopting a new technology having to cobble together a disparate number of tools to create a good editor experience, especially in a time where as a novice I'm actually not at all qualified to understand what a good editor experience would be! I actually call this the Clojure Problem, which is that many Clojure devs decide they have to learn emacs or a complicated fireplace.vim setup in addition to Clojure and wind up learning neither.
Regarding speed, don't get me wrong, I empathize with complaints about it and whenever I'm doing C# work for one of our services I'm reminded of just how slow developing Scala can be in particular. But I don't think of LSP approaches as fast, either. Perhaps they are async and don't block the UI, but now I'm just sitting here typing and getting constantly out of date feedback from the editor as it and the LSP catch up to whatever text has been entered.
But it still needs to mature quite a bit before I’d be comfortable saying it’s anywhere near Django or Rails
It can also generate clients and webhooks. Authentication is just declaring a SecurityScheme in the OpenAPI document then implementing a single function. The rest of the backend is just implementing a single interface. Unlike oapi-codegen, there is no need to tinker with routing libraries or middleware for authentication and logging.
Pair this with sqlc[2] and SQLite's `pragma user_version`, and you get type-safe database code and database migrations for free. I will concede that adding SQLite is a manual process, but its just two imports added to main.go.
Frontend is entirely your choice. Go's standard library provides good enough text templating that I don't miss ERB or Django-style templates. Using the standard library's `embed` package, one can easily embed static assets into a single binary, so deployment can be as simple as `go build` and moving the binary.
I have a hard time using languages besides Go for developing backends, because the code generation tools make Go as convenient as frameworks like Quarkus while staying lightweight and fast.
You are missing the entire point of Rails and making the OP's point for them.
> Go's standard library provides good enough text templating
Rails offers much more than this, this again makes OP's point for them.
In contrast, RoR or Django provides a nice rubric to get you up and running quickly. That said, I still like Go when I need to spin up a microservice with a well-defined scope.
There's a lot of noise coming from Microsoft to sell their new products (this year: Aspire.NET). But don't be mislead by this noise: .NET Core (C#, ASP.NET Minimal API or MVC, EF Core) is more batteries included and reliable than most other options. The only gripe I have is the need to get into the OOP and DI mindset ("create custom implementations of some abstract classes and put them into DI and the framework calls your implemented methods magically" kind of stuff). Takes some time, but not a big deal for experienced devs (and younger ones can learn faster anyway :-)).
My gut still says rails for customer facing, Django for internal tooling or data work.
[1] Stop Designing Languages. Write Libraries Instead:
Spring is an industrial factory that is good for huge teams, because it acts as a straight jacket.
I get that there are poor workplaces making Spring applications a hellscape, and some of those folks escape to go do (let's say) Rails. Others may decide that Java and Spring are fundamentally fine, but need to be used in better ways and then they do so, we're not all idiots (not suggesting that you said so).
Java, Kotlin, Scala, C#, F#, OCaml, Haskell, D, are also much better for networking tools and CLI.
And nowadays people can't even complain the Java AOT options are commercial, or .NET is stuck on Windows.
Touché!
> Java, Kotlin, Scala, C#, F#, OCaml, Haskell, D, are also much better for networking tools and CLI.
Maybe. But I wouldn't touch any CLI written in a Java, Kotlin or Microsoft Java with a 10-foot pole. YMMV.
One can argue it goes against some of the Go principles, but it's a really nice stack for solos or small teams without dedicated SREs. And as you grow you can BYOC & deploy it yourself or completely rewrite your API layer using Go stdlib.
You would still need NextJS or Remix/RR7 for the front-end, but one nice thing is that it would auto-generate the client SDK in TypeScript which makes integration a breeze. And while I personally prefer Remix/RR7 for frontend, Encore has integration with Vercel PR feature which is really hard to beat.
These features are great for established apps like GitHub and Airbnb, but if you're making a tiny startup, and want to test ideas quickly, I wouldn't spend time on CI, caching, Rails's authentication (use extremely feature rich Devise gem), Rails's 'turbo' features, and writing tests. These are all good things for medium or larger apps, or well-funded apps with a long run way, but are usually cost-benefit negative for small apps.
Turbo saves a fraction of a second on many page loads, but can add days of development time for those not fluent in javascript when it causes some core functionality to not work (e.g. devise's Log out!). Testing is very important on large apps but for quickly flicking a few ideas together and getting it in front of users; unless you're a banking or healthcare app, they can probably be postponed until you have traction.
Be mindful of your size and timelines and don't succumb to 'default bias' where you use things simply because they were there out of the box. Feel confident to say 'no, we don't need that (for now)'.
I’m also not sure how much time you imagine one spends on setting up CI. In my case it’s just one file with about 20 lines in it, and I usually just copy and paste it from previous projects.
The problem is when it breaks due to some versioning issue or some other easy-in-hindsight problem that saps 3-6 hours of time that could otherwise have been spent talking to users and discovering/building real features. I start to question "did I really need CI in the first place", I think the answer for non-critical apps (e.g. with a small number of users; not healthcare/banking/similar) is usually a hard "no". Other than autonomously running tests what value does CI offer?.. to me, nothing that I can think of. Not saying everyone should denounce it, just that it's very okay to say 'nope, don't need it (yet)'.
Maybe I would have if I didn’t.
I appreciate that they wanted to keep Kamal simple, but rebuilding a Docker image each time you deploy a tiny change feels like a waste. Capistrano just does a 'git pull / bundle / server restart' which seems much more elegant.
Of course, things like upgrading to a new ruby version become much harder with Capistrano's model, you need a separate process for a small release and a big release. But those things happen twice a year, on small projects you can do those manually until you have time to set up Kamal / Terraform / Ansible.
Jumpstart Pro is great. https://jumpstartrails.com/
So is Bullet Train. https://bullettrain.co/
Rails was one of the first web frameworks I learned after PHP and it and Ruby were always favorites of mine.
Closest I came to being a Drupal dev was shipping a small CodeIgniter app in around 2011 (right before picking up a Rails book).
Asking out or curiosity.
With much of the AI development happening in python and typescript, you might be right about those areas.
But if you are sticking to basic web/database stuff it's hard to go wrong with RoR.
I've done both and I find that in Django I had to resort to more manual steps than what I'd do in Rails.
The testing story is also better in Rails compared to Django, that's not even close.
Rails gives you way more structure than Django.
Ruby was my first language and it didn't take me long (maybe a week of very part time tinkering) to learn how to make a basic 2D platformer game, or scrape the web for financial data and throw it into a database. The first time I made a Rails app it took maybe 30 minutes, to go from nothing to a basic CRUD app that does things and is online on Heroku.
In a professional context, I've heard of non Ruby devs getting up to speed pretty quickly. And as much as there might be to learn mastery, it's still a dynamic language that takes away most details for you (like managing memory) so you can definitely be useful far quicker than if you were to learn C, Rust, Haskell or shudders C++.
It can be one of the most pleasant languages to read, but a lot of hidden knowledge is required to write it like Ruby wants you to.
Using Rails? Read Rails documentation.
Using bare Ruby? Read Ruby documentation.
And literally every programming language is like this. C# won't contain Unity C# classes. Basic Python won't have Numpy classes. JS won't have React functions. And so on. Also it's not like Ruby is the only language to ever have monkey patching...
It's absurd that this is being brought up as a Ruby weakness when both the Ruby website and the Rails website each have amazing documentation and if you actually read the documentation, go through tutorials, it's all laid out very clearly.
https://www.ruby-lang.org/en/documentation/
Dunno, whenever I learn a new language, I read the official docs. When I learn a new framework, I read the official docs. Even when I was an absolute newbie, I learned from the resources on the official website.
When they taught us programming in school, Scratch was the first thing they taught. Then Python. I was in Econ as opposed to CS so then it shifted to Stata and R (for those who didn't want to pay for Stata and were more into current trends). For dropping down to low level, Fortran.
I guess where I'm getting at is maybe I just learned at a particular time when there were lots of programming languages that didn't have braces and were popular? Dunno. C was seen as low level sorcery, C++ was for games, Java I guess did become popular by the time I was in university but only the CS kids destined to become enterprise programmers used it.
All the "learning" languages I encountered didn't have braces. Nodejs didn't exist yet. So yes, Ruby was very intuitive. It read almost like plain English, had very consistent syntax and was very accessible on Linux systems (which were becoming more common and already very good by this time). Being able to just "blah install Ruby", then open a REPL, have an interactive environment and run things immediately was very easy.
I also like ActiveRecord + Arel more than the Django default ORM, but that's more so preference driven by like the Ruby AR syntax more than the Python. (And a general unsupported opinion that Ruby is a slightly better/more pleasant language for writing code than Python.)
If I was building a web ‘app’, consumer facing product, I’d reach for Rails. I think scaffolding up to ‘market ready’ seems easier in Rails. I say this having never really done this in production.
For internal tooling (using the admin panel), data based work, or geospatial work, stick to python
Obviously Django ties you into python and its ecosystem while Rails means ruby (and its gems). The ecosystem is more important than the language. This can either impact your project a lot, or not much at all, depending on context.
Rails doesn't have the equivalent of Django's admin CMS. There are gems but Django is still much stronger. A lot of orgs have their entire CMS / administrated-by-staff part of the product written in it.
Rails, otoh, has a very powerful scaffolding cli. If you are proficient, you can generate some basic crud stuff in minutes from A to Z.
In general, I think Rails is at an even higher level of abstraction than Django. A lot of the architecture or structure is more or less given with rails, whereas you need to make a lot more choices with Django yourself. Routing is a good example. The 'batteries' that are included are also a bit bigger and seem to be in much more active development than Django.
Also a generalization: rails/ruby seems to value brevity and the DRY principle a lot more than is common in django/python. There's a split in taste on this, often python devs find the 'magic' of Rails rather frivolous and unreadable - even though django has a fair bit of metaprogramming itself, whereas Rails devs think the 'pythonic simplicity and straightforwardness' is actually rather crude. Or to be a bit more precise: in the rails world, code duplication seems to be thought of as a greater evil than semantic coupling.
I realize these are all quite subjective, and probably reflecting my own development experience more than being an accurate feature-by-feature comparison.
It makes everything great, and every new surprise is like discovering that your new special friend also knows how to juggle! And speaks Cantonese! How cool is that?? Oh, they’re afraid of spiders? How cute. But did you know they went to Ecuador in college?
There’s a honeymoon effect that just never stops, whereas for me it never started. I’m actually jealous.
At the same time, I am always shocked out how many people fight against Rails conventions when building in Rails. (Not that you've done this, but seriously, I take over a random code base and they'll have done something like written a worse version of Active Job from scratch for no real reason.)
But in the rails context couldn’t you mostly manage with an ActiveRecord validation? I know it wouldn’t be ideal.
IME you usually want _both_ the Active Record validations, and the database-level validations, because you get better error messages from the former, and the latter is just a safeguard.
Or any other constraint for that matter, every few months I look for ADD CONSTRAINT again, only to rediscover there isn't anything.
The lack of any sort of PL language (or even just trivial stored procs aliasing queries) also makes migrations more annoying, CTE can handle some of the load but the verbosity and limitations of basic SQL make that awkward, and needing to round-trip through the host language for everything is frustrating (even more so when the host language is statically typed and thus requires adaptation out).
That said, I do think it's really positive that sqlite3 is now a first class option in the framework. Tons of high quality work by very smart people has been invested in recent years.
EDIT: this comment is more about rails itself than the actual blog. I take the point being, that sqlite is fine for starting out with a tiny app if you have very little users, and I think that is true.
However, migrating later on to a different database is a always a pain, so I wouldn't recommend starting out with sqlite if you intend to do that later on (with your production data).
For real. I put together a simple Jekyll blog, and figuring out gems and this and that after not looking at Ruby for 15 years was a real slog. A lot of that was my fault for being out of the Ruby loop, and being unfamiliar with Jekyll, but I feel like the process could have gone a little more smoothly.
Anyway, this made me excited to try Ruby again.
Nooo the setup should be easy no matter how experienced you are.
I found jekyll quick to get started with, but that is because I already had Ruby and RubyGems installed.
I've not used it myself, but I am going to rewrite one of my projects that I only use locally from postgres to litestack. The benchmarks are incredible!
https://github.com/oldmoe/litestack/blob/master/BENCHMARKS.m...
What they meant was https://github.com/oldmoe/litestack which has a lot of things built on top of sqlite, like job queue and caches. Rails 8 now comes with most of them out of the box.
My SaaS ran on litestack until rails 8 came out, then I switched without problems.
Another thing that I noticed is that if you compare litestack's benchmarks to solid_cable (for example) litestack claims to outperform redis whereas the argument for solid_queue is that it is slower, but worth the simplicity of 'just using the database': https://github.com/rails/solid_cable?tab=readme-ov-file
All in all I would prefer 'the standard' solution, but I am interested in experimenting with litestack. After all that is what side projects are perfect for.
* Want to allow your users to write rich text? Easy just use ActionText * Storage and attachments? ActionStorage is easy to setup * Job queue, asynchronous work? No problem with ActiveJob
Today I learned about Rails system tests and found it so cool. With almost no configuration I can write tests that interact with my app through a headless browser.
Rails is the ultimate solo developer and hobby project tool for me
with scaffolding and other rails generators with custom templates is that really a big asset? might not look amazing out of the box but you can find css templates easy enough too. maybe they should make an admin generator but rails is king of crud and if you need it ootb you can use one of the many gems.
Yes, of course, _there's a gem for that_ but after having used Django, it's really very nice to have those features included and not have to spend any time thinking/arguing about which Gem to choose and remembering/endeavoring to keep that Gem patched, etc.
administration zero doesn't do much other than install a few gems, and include a scaffold that you can use to generate admin pages akin to django but you do get pagination and search and filters added on top. no magic though just rails scaffolds. https://github.com/lazaronixon/administration-zero
I know there are a few other projects like this which I’ve seen over the years, but I’ve yet to truly investigate any.
I would love a basic admin interface plus some auth.
It would be cool if rails mirrored some Devise helpers so that Pundit/Cancancan worked out of the box.
just a thing to install an admin generator scaffolds which you control fully after the fact. no magic just generators.
I think it offers a lot of the same developer experience and convenience that the rails generators do, though obviously in a different way.
I’m doing a side project in Go right now, which is decidedly not “batteries included”, and I love it. Go and htmx are kind of a match made in heaven. That doesn’t mean I think Django Admin or Rails Scaffolding are useless, they’re just a convenience. I rolled my own login system, cause it’s fun. Is Django user land or Devise more secure? Absolutely. Is it necessary for what I’m doing? Nope.
My personal preference is that if I’m doing app design or consumer facing work, Rails seems stronger. For internal tooling, data analysis work, or geospatial work, I reach to Django to have those Python libraries available.
Last time I programmed with rails was many years ago, but none of these things are included in the default scaffolds right?
I understand the comparison with scaffolding, but I don't think they really overlap too much. You'd typically throw away a lot of the generated scaffolds from rails for a production app. They are more of a tool to avoid having to manually write boilerplate code, increasing productivity and (maybe) reducing errors. But django admin interface is meant for production, though often more as a backend tool than a customer facing interface. Different purposed. I miss the scaffolding in django and the admin interface in rails.
Yes, it is. Django CMS just hits that sweet spot where you can do almost everything you need for an administrative backend with very little customization. Because there is a convention of how things hang together, you are that much more productive. Its kind of a cms that you can throw together programmatically, it sits at a higher level than scaffolding + templates.
Honestly it feels, ironically, like a very rails-like thing to do (here's my model, you know all about it: now generate an admin interface for it!), except that in the rails world it would be unacceptably ugly (in various ways). But it is this very ugliness that prevents you from exposing it to consumers, or spending more time on it that it really needs, so it tends to stay in that sweet spot of being just good enough to do its job. It is very pragmatic and effective.
Is it a must-have? No, of course not. You can DIY an admin interface with rails very easily, too easily almost. However, the same thing can be said about pretty much anything that rails has got going for it: you can DIY in django/python too. And there is always a package...
Plus, nearly every static site ends up with someone saying, “oh I wish I could ____, but it’s a static site.” Instead of needing to pick a client-side-only solution, use a third party service, or integrate with a cloud Functions as a Service provider, Rails and a production-ready database are right there ready to help.
Save me from my free tier GitHub pages / Netlify / SaaS hell.
This is the hottest tip in this thread imo
Depends on how you like your hell: Now you're on the hook for security updates to the full stack.
I think that the doctrine of convention over configuration leads to content that is much more legible to LLMs in training. I find querying Claude for Rails issues to be really helpful. I suspect would be very helpful to a novice.
# change directory_on_your_machine_for_think_db_storage docker run -d --name thinkdb -p 3000:3000 -v directory_on_your_machine_for_think_db_storage:/app/storage thinkthinkai/think_db:latest
TADA.. Rails is great.
With the recent Rails updates, even in Rails 7, Devise didn’t seem that useful and seemed to over complicate the user authentication, registration, lost password experience and also seemed like I had to do a lot of work overriding their views to fit with my application. It seemed easier to not use Devise? It had its usefulness in earlier versions of Rails but not so much now?
I also find devise pretty simple to get setup and use. It's so easy to mess up some small thing while writing your own auth. I've always pretty much trusted myself to at least get devise setup properly.
[1] https://github.com/18F/identity-idp/blob/main/Gemfile#L30
If you put the money the government steals from your paycheck for "Social Security" into your own private investment account and invest it in the S&P 500, after a 40 year career you would have about 4x the income that Social Security will pay you for the same malinvestment in their broken system. That's now. In the future, we will probably have to net pay Social Security when we retire.
The FDA put candy on the food pyramid, as a part of our daily diet.
The F-35 Lightning project was managed by the government, and, as a result, the United States will likely lose the next major nation state war we enter. But, because of that selfsame government's other skills, the United States will likely be bankrupt and gone before that happens.
Everything the government does is worse; no, the worst. If the government does something, that's a really good reason to look at alternatives.
As a SWE and infosec guy, please don’t just roll this stuff yourself. Maybe Devise is more complicated than it needs to be, but a lot of this stuff is far more subtle than people realize and trivially easy to get catastrophically wrong.
I’m absolutely certain a lot of the parts you think are unnecessarily complex are the result of having gotten it wrong before. How do I know? Because I’ve personally submitted vulnerabilities to Devise (specifically the lost password flow) that ended up getting a redesign to fix the vuln.
So even if you don’t use Devise, please use some other project which has already suffered through iterating over vulns so you don’t have to.
Rails 8 comes with a basic auth generator: https://www.bigbinary.com/blog/rails-8-introduces-a-basic-au...
There's also https://github.com/lazaronixon/authentication-zero that goes beyond that.
My pet peeve with most of the auth solutions is that they tend to be extremely coupled to hard-coded emails, which makes it varying degrees of annoying to use third party tools for the parts of a product funnel that intersect with auth and also to integrate SMS cleanly. But I guess I'm the kind of person who finds it annoying to override a "send invite email" method with something that triggers events or sends an SMS instead just because it's not really what it says on the tin at that point.
Yes, it can seem esoteric and magical (in the bad way) until you wrap your head around the idioms and design philosophy. There's a lot of functionality that happens unless you override it. I fully get that this rubs a lot of people who aren't in the pool the wrong way.
However, in addition to the impressive selection of modular capabilities mentioned elsewhere in this thread, there's a very bright light that goes on when you realize that you can make powerful changes to the way the library works by reopening a few controller classes and defining your own methods.
My strong advice for anyone looking at Devise and perhaps feeling stumped is to open up https://github.com/heartcombo/devise/tree/main/app/controlle... and spend some tens of minutes looking at how the library does what it does. These controller - especially sessions and registrations - contain all of the business logic driving the "magic". Not only do they reveal themselves as relatively simple and well thought out, all of those yield calls mean that you can call those methods while passing a block to them. Whatever is in that block will be evaluated inside of that method when it runs.
The people who designed Devise put a lot of thought into this stuff. When you get it, you suddenly don't want to be without it.
[1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
We were getting data through a partner who restricted our data access through an API, where we were limited to 100 records per call. Turns out discussing Spark vs Duck DB isn’t helpful if 99.9% of your software latency is from having to make 750,000 HTTP calls every weekend to run your BI pipeline. For the record, that API was a Rails app - but it was certainly not the fault of the framework in that scenario.
Point being, for web apps, I don’t think it matters unless you’re in the top 100 websites, and even then it probably doesn’t. Complaints about htmx efficiency always confused me for this reason. Your app isn’t slow because you rendered HTML instead of JSON.
Sorry to digress, others may know better than I do but this one is just my experience.
The only time I’ve run into computation speed bottlenecks in either was doing data analysis in Python, and you usually just bring in Python libraries that aren’t written in Python like polars or DuckDB. Sounds dumb, but it works pretty well.
Standard practice has always been for me that long running tasks get sent to a job queue anyways. So ideally nothing in the UI is dependent on something that is long running. But again, in my own work any long running tasks is almost always limited by network latency.
So if I have to do a little brain damage to configure Kamal but then can push sites to it easily? I’m in
I guess the work on performance and tooling has paid off and people are starting to realize that if python can have the spotlight then ruby (overall a better language) might deserve it too
Elixir very similar to ruby in syntax and Phoenix very similar to rails in functionality.
The creator of elixir (Jose Valim) was a core rails contributor back in the day IIRC
My company (founded 2007) was built on Rails and that B2B app now has 200,000 customers… all on a Rails monolith, the same code base that has evolved with Rails over the years. It’s not just for side projects!
That’s said, I run my current side project on Rails 8 and Postgres (I don’t get on with SQLite). You can do so much with so little code! Inspect the source code here if you like :) https://github.com/lylo/pagecord
I’ve always liked Vercel’s approach for these kind of side-projects, as I don’t have to worry about cancelling anything if I stop using it. But I guess that is a perk of it being serverless, which precludes Rails. What’s the next best option, something suitable for small, database-driven Rails apps?
Those of you who struggled with the same dilemma, what did you do?
But I'd be interested to know where Python is more useful, apart from science, data science, ML, AI, and such.
Python also has far stronger typing story, it is used as a glue in many orgs (just look at Mozilla, Chrome and countless more codebases), there's also an order of magnitude more people using Python which means far more nicer LLM story.
On the other hand Ruby evangelists swear by Ruby like it's the second coming, so there must be something that makes people so happy. I'm trying to understand if it matters enough to pay opportunity cost for switching to Ruby.
And yes, I know that you can learn both, but becoming proficient in languages takes time and practice. Ruby isn't something that I'll be able to sell at my org, which means I'll have to invest into it in my own free time. On top of that you have to stay up to date with language developments if you want to stay relevant.
> 762 vs 20k hits
That's impressive! I guess the difference is smaller here in Berlin as we have a lot of rails shops, but internationally speaking, your stat might well be representative. There might also be less competition in the Ruby job market, but perhaps not to such a degree to offset the difference in job numbers.
In the end, Python is probably the safer and more career friendly option, especially if you're interested in AI. However, if you enjoy coding, Ruby is IMHO the top choice to maximize this enjoyment. I don't think it's the second coming, but there's no other commonly used language where you can do things as easily and so without bending to any limits of the language. The downside of this power is that you're never done learning about it. Maybe people who are drawn to coding as a hobby are more likely to enjoy Ruby than those with more of a separation between work and private interests.
what's hardly ever mentioned is how great hotwire is. it takes time getting used to, documentation is sparse but oh man oh man - hotwire is nice. you get to skip a majority of spa shenanigans.
One of my colleagues recently switched from mostly react to default full stack Rails. He was really struggling with how to filter things in a table. When I showed him how I would do it, his comment was along the lines of: “I can’t believe how simple this is. Modern JS just doesn’t work this simple any more. This is like how jquery used to work but way more organized”.
I can’t say I know enough about modern js development to validate that comment. He noted something about expectations of how the dom managing things…
So, if you’re coming with a certain mindset of how to do things, try to leave that behind a moment and read through the handbook. Especially if it involves making fetch requests to do things. That’s like, the number one “you probably shouldn’t do it like that” in Hotwire.
then this series on youtube - https://www.youtube.com/watch?v=b7dx1Yt3FzU&list=PLm8ctt9NhM...
some things have changed a bit - so you just have to work through the kinks.
one other thing though - since railsword conf - there was an announcement that certain things have simplified but I haven't found the docs or the new simplified api's.
I don’t know if that’s helpful, but realizing that I needed to shift from thinking about components to pages was the a-ha when Hotwire all started making sense.
Running Postgres and Redis in Docker is a matter of adding a few lines of YAML to a file once and never thinking about it again. I have done this for 10 years, it is painless.
I'm all for reducing moving parts and would also choose the same strategy if there were no down sides but DHH is running their apps on dedicated hardware with some of the best performing SSDs you can get. Most VPS providers have a lot worse disk performance.
There's also downsides to running your DB (SQLite or Postgres) directly on your single VPS when it comes to uptime. If your server is stateless then you can upgrade it with zero downtime. All you have to do is spin up a new server, provision it, add it to DNS, wait a day or 2 and then decommission the old one. This is nice for resizing instances or big OS updates in a zero risk way. You can just make a new server.
That works because it doesn't matter if the old or new server is writing to your externally hosted DB. If your DB is directly on the host or using block storage that can only be connected to one instance at a time then you can't spin up a new server since one of the DBs will get out of date.
> it is painless
Huh, I wonder why.
I didn't start with 10 years of experience if that's what you mean.
A basic Redis config inside of Docker Compose could be:
services:
redis:
image: "redis:7.4.1-bookworm"
restart: "unless-stopped"
volumes:
- "redis:/data"
volumes:
redis: {}
It's similar for Postgres except you'd also want to set the PG username and password with environment variables so your initial user and DB get set up with reasonable defaults.
A working version of this is in my Rails starter app at: https://github.com/nickjj/docker-rails-example
It sets a few more properties but those aren't essential to get going.
Of course clearly not all apps are GitLab, but GitLab is the only Rails app I run, and must be one of the most problematic software I've ever deployed for security patching, and most of it seems to do with issues in the Ruby side of things. What makes GitLab so uniquely crap at security, and how do you avoid it as a Rails developer?
I think the answer to your question is the same as any large application: pay attention to your supply chain, architect your systems well, if you don’t know how to do things securely go learn before building (or learn as you go, but that has consequences typically).
- PHP had a really good developer experience (even with the rough edges, for the time), but building robust applications on PHP could prove quite challenging. It has gotten a lot better, but there are still remnants all over from the past.
- Ruby, likewise, seems to have a really good developer experience, and indeed it seems Rails apps sometimes suffer with robustness and reliability. Not just GitLab, but also Twitter in the past, too.
I think some people may read what I'm saying and think I'm just a hater, but not really. I actually just wonder if what I see with GitLab is telling us more about GitLab, or if it's telling us more about Ruby or Rails. Is it hard to make robust Rails software?
> I think the answer to your question is the same as any large application: pay attention to your supply chain, architect your systems well, if you don’t know how to do things securely go learn before building (or learn as you go, but that has consequences typically).
This is good general advice but I am aiming more specifically. I'm wondering if anyone with more expertise could answer to what classes of issues you have to work to avoid. I know Shopify was working on gradual static typing for Ruby: is dynamic typing a problem? That sort of thing.
Of course, you can write both secure and insecure code in any programming language in many different ways, but some ecosystems make it easier and harder and I think that's more what I'm getting at.
Frankly, even if it's true that it's tricky to make Rails apps secure, that wouldn't really dissuade me from still using it in some cases if it seemed like it could save me a lot of time and effort. That's pretty much exactly why I used Django to begin with; I definitely don't feel like Django was the most robust platform to write webapps in, just a very productive one (that was still decently robust in my experience, but you know, YMMV.)
I don’t see as many CVEs, at least to my knowledge, with GitHub or Shopify. Not that they haven’t happened, but seem to _much_ less. Stripe is mostly ruby, though not rails, and have done well with security.
My suspicion from outside of Gitlab is that it’s a quality and prioritization problem. Security is hard. It requires very deliberate decision making and investment. Ruby and Rails are generally very stable, but you can use them to crazy ends if you allow yourself to.
I’ve done one app with Hotwire Native and it’s a pretty interesting solution. However, just like a truly complex and dynamic web UI can reach a level of polish with React that is hard with Hotwire, a truly complex and dynamic mobile UI can reach a level of polish with Swift/Kotlin that is truly hard with Hotwire. It makes the vast majority of experiences much faster to build, but certain complex experiences are hard to get polished.
However, Hotwire (web & native) can get you almost the full way there and you can just drop a React/Swift/Kotlin view in for parts of the app where you need it.
I hope as an industry we can move away from this "___ is dead" talk. The OP shouldn't even need to say this. If something is being worked on (in any capacity) and has at least one user, it isn't "dead."
"Is it dead" is groupthink questioning that leads to great ideas being swept under the rug because they're not perceived as popular enough.
Think for yourself and use the tools that make sense to you.
I don't use it and you may not but it still has an active community and job listings. The last release was on December 20th [1].
This is what I'm talking about: it may not be popular in a "bleeding edge" sense, but it's still being used and developed.
Specifically, it might be useful to know if a once very popular (dominant in some circles) framework is significantly less so. That downward trend might be relevant for someone, somewhere. "Dead" is still probably not the right word.
Maybe it’s stereotyping, but I strongly suspect users of Trendy technology are more likely to be vocal about it, including by answering surveys, and especially in online forums. I’m personally a PHP developer, one of the least Trendy technologies, and you’ll never see me loudly talking about it like a JavaScript developer. The internet, and frankly HN, would tell you that a language with over a billion Docker pulls isn’t worth learning.
In an ideal world, you hire engineers who have a breadth of knowledge of programming instead of specializing in one language/framework, and then it doesn't matter if a language is "dead" or not, you just pick the best tool for the job. Unfortunately, there's not enough good engineers to go around for such a strategy. As it stands, I would estimate that most people employed with the title of "Software Engineer" barely know what they're doing
I tried hard to find an alternative that could sway me away from rails, but I could not find anything I felt nearly as productive with or enjoyed more. I'm kind of relieved rails is having a comeback. All of the good stuff of rails never really left. People just got too pulled into SPAs and microservices, and rails 8 just showed many who are paying attention how much better things can be.
The group think of SPAs and microservices has been crazy to me. I don't think devs took the time to fully consider how much complexity they were accepting with SPAs and microservices. Certainly SPAs and microservices have their place, but not for everything.
Apparently that's one of the few things you can do well with a rails app. As evidenced by all of the rails apps stuck behind 3+ major versions because refactoring or upgrading without breaking everything is damn near impossible.
I've done a ton of rails upgrades in my career, they've all been easier than any other framework (except the current batch of js/ts frameworks that use codemods to update the majority of breaking changes).
DHH has been making some pretty wild changes with non-Ruby parts of Rails, but Rails 8 still fully supports sprockets, their asset pipeline introduced 15 years ago. All of the other asset pipeline alternatives are still supported, even though Rails introduced "Propshaft" as a replacement.
The only thing we've had trouble with upgrading has been when Rails added full support for read/write shards... it wasn't fully compatible with Aurora Serverless at launch, but we had wanted to migrate off that anyways.
So.... try adding some signal instead of just noise. Cite specific issues, rather than just try to ride a bandwagon.