Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails for everything

literallythevoid.com

Post reply on HN
Print view View original

71–80 of 250 posts

Re: Rails for everything

#71

Post by ismailk »

rednafi wrote: post #50
najarvg wrote: post #31

Earlier quoted context omitted.

Not hands on with Django (or other Python based frameworks) so pardon the basic question. How do the speed of the generated application compare with the speed of a generated rails application? I know the latter has made some strides recently..

Python is generally faster than Ruby, especially in the newer versions. That said, we’re still talking about two of the slowest languages out there, so the performance gap probably isn’t that big.

This was generally true before the introduction of YJIT, but with YJIT, Ruby's performance has improved significantly and may even outpace Python in some scenarios[1].

[1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Rails for everything

#73

Post by wmoxam »

WD-42 wrote: post #55
tyre wrote: post #41

Earlier quoted context omitted.

Ruby and rails’ ecosystems are also massive. Devise and ActiveAdmin are options for those two, though I haven’t used either in years. With much of the AI development happening in python and typescript, you might be right about those areas.

RoR's ecosystem is indeed massive - for web apps. But if you want to make an app that integrates with an existing domain, Python is just so far ahead. Numpy, SciPy, Pandas, basically the entire field of astronomy and biology, data science and FinTech... the list goes on. But if you are sticking to basic web/database stuff it's hard to go wrong with RoR.

All of that extra stuff can still use Python and integrate easily with an RoR app. Typically your astronomy/biology/ata science stuff isn't needed in the context of a request and is done asynchronously

Re: Rails for everything

#74

Post by Glyptodon »

rich_sasha wrote: post #12

As someone who doesn't do enough web dev to justify learning Ruby just for Rails: how does it compare to Django? That's the only batteries-included web backend framework I'm familiar with... Asking out or curiosity.

Historically, Django Admin is better (in terms of ease of use and flexibility) than anything equivalent in Ruby, but Rails has better conventions for tests and routing. (Or at least that's my opinion.)

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

Re: Rails for everything

#75

Post by schneems »

block_dagger wrote: post #13

As a single developer of an open source Rails project that has grown to serve ~120k MAU, I can attest to this article’s claims. One tidbit to add: ActiveStorage, which provides file attachment features, is another excellent piece of the Rails family. I’ve been using Dokku but looking forward to trying Kamal. Rails keeps getting better, and Ruby keeps getting faster.

If you like dokku, have you seen Cloud Native Buildpacks? You can build an OCI image from them as a first class feature https://github.com/heroku/buildpacks/blob/main/docs/ruby/REA...

Re: Rails for everything

#76

Post by nomilk »

> if you follow (the Rails Guides) start to finish, you'll have a Rails app in production. And it isn't just hello world. Your app will have authentication, caching, rich text, continuous integration, and a database. That's a real application.

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

Re: Rails for everything

#77

Post by shepherdjerred »

dismalaf wrote: post #45
rich_sasha wrote: post #12

As someone who doesn't do enough web dev to justify learning Ruby just for Rails: how does it compare to Django? That's the only batteries-included web backend framework I'm familiar with... Asking out or curiosity.

Ruby doesn't really have a learning curve... Maybe block syntax but that's super easy. Rails gives you way more structure than Django.

Ruby _definitely_ has a learning curve

Re: Rails for everything

#78

Post by Glyptodon »

hk1337 wrote: post #22

I’m curious on others thoughts on whether or not to use Devise? 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 Rail…

I don't like Devise. Rodauth covers similar ground in what seems to be a slightly better way. I know there are some other options.

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.

Re: Rails for everything

#79

Post by hatsix »

dismalaf wrote: post #45
rich_sasha wrote: post #12

As someone who doesn't do enough web dev to justify learning Ruby just for Rails: how does it compare to Django? That's the only batteries-included web backend framework I'm familiar with... Asking out or curiosity.

Ruby doesn't really have a learning curve... Maybe block syntax but that's super easy. Rails gives you way more structure than Django.

I tell people that Ruby is a language optimized for reading. Things just make sense when you are reading what someone else wrote, but it can be much more difficult to write something from scratch with no guidance. Take dates, for example. Let's say you are fixing an issue, validation was set to accept one week in the future, but should have been one day in the past. 1.week.from_now becomes... well, how do you look that up? You head to the Ruby Lang site and look up Integer, but Integer doesn't have `.week`, so now you have to rely on Google-fu to find what you need, but you'll get a mix of base Ruby and Ruby on Rails, which modified base classes with some syntactic sugar. Eventually you find 1.day.ago and file that away, only to go through the same research for the next line you need to change.

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.

Re: Rails for everything

#80

Post by Glyptodon »

shermantanktop wrote: post #65

There’s a thing here that seems to separate people like the article author from…well, from me. They just have a deep, deep affection for Ruby and Rails. 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…

Personally, I don't like a variety of things about Rails. Like its love for pluralization of everything. But every time I've wanted to have similar productivity with say, a Javascript backend, I find it basically impossible.

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

Post reply on HN