Live data from Hacker News

Rails for everything

literallythevoid.com

81–90 of 250 posts

Re: Rails for everything

#81

> Rails is not dead; It's better than ever. Try using it to make something new this year. 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 had a much better time moving Rails code bases through version and library changes than JS, PHP, or Python ones. But I think that might be nothing more than Rails code bases being more likely to have some sort of test suite that covers some meaningful application surface.

Re: Rails for everything

#82
post #71
post #50

Earlier quoted context omitted.

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

Yeah, Python 3.13 got some great performance improvements as well. But both languages are quite sluggish compared to something like Go and even Node. Also, while I like Ruby, other than RoR, I wouldn’t opt for it to build something.

Re: Rails for everything

#83
Ruby and Rails anre amazing. I love Rails and recommend it for most small to medium sized projects. What I find frustrating though is the constant hum of people using “Ruby is slow” as the excuse for every problem they have. Everyone I know using Rails is in the process of convincing everyone that they have outgrown its capabilities and need to move onto something “more mature”. I also see a lot of people using Rails but replacing its components with others. A. If part of what makes Rails powerful is that it comes with pretty much everything you need, replacing them without good reason (there usually isn’t one) erodes the value you get from Rails.

Re: Rails for everything

#84
post #32

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.

The biggest difference is python vs ruby. Python’s ecosystem is massive, so if you want to pull in any third party libs you have plenty of choices for whatever you may need. Django also has auth and the admin interface built in, both of which are very nice.

Python might be bigger outside of the web but for any Web app, Rails wins hands down on the amount of battery included software that exists in my opinion.

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.

Re: Rails for everything

#85
post #76

> 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,…

I don’t agree with your position on tests. I find that writing tests even for small applications saves me time. And that’s even in a language with a sophisticated type system.

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.

Re: Rails for everything

#86
post #51
post #47

Rails is awesome, and so is Django. I’ve built mission-critical apps in both and still do with Python. That said, I’d love to switch to Go for building large monoliths since it has a tighter type system and better concurrency constructs. 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.…

I don't think Go was trying to capture that space really.

Go initially tried to capture the C/C++ space and failed miserably. Rob Pike lamented[^1] over that in a famous blog post. It got the most love from people coming from Python and Node. Then it became the defacto language for writing networking tools, and to this day, it holds that crown.

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

Re: Rails for everything

#87
post #86
post #51

Earlier quoted context omitted.

I don't think Go was trying to capture that space really.

Go initially tried to capture the C/C++ space and failed miserably. Rob Pike lamented[^1] over that in a famous blog post. It got the most love from people coming from Python and Node. Then it became the defacto language for writing networking tools, and to this day, it holds that crown. 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…

Go is best at interfacing with kubernetes, which I think will carry it pretty far, for better or worse.

Re: Rails for everything

#88
post #47

Rails is awesome, and so is Django. I’ve built mission-critical apps in both and still do with Python. That said, I’d love to switch to Go for building large monoliths since it has a tighter type system and better concurrency constructs. 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.…

Node/Express is my goto for quick and dirty picoservices that only really run on local developer machines. Asp.Net WebAPI or MVC is my ideal backend stack

Re: Rails for everything

#89
post #76

> 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,…

I don’t agree with your position on tests. I find that writing tests even for small applications saves me time. And that’s even in a language with a sophisticated type system. 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.

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

Re: Rails for everything

#90
post #38

> Rails is not dead; It's better than ever. Try using it to make something new this year. 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 pop…

Many people choose what language to invest time in based on the labor market for that language. Companies shouldn't be so religious about the languages they use, but for small teams they usually pick one language for the entire company so that devs can hop between projects without any linguistic learning curve. Hence why there are so many Node + React companies out there; you hire a bunch of react bootcamp grads and they can quickly start working on backend features as well since they already know javascript.

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

Post reply on HN