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

Choosing Ruby on Rails for web development project in 2019

ideamotive.co

Post reply on HN
Print view View original

111–120 of 216 posts

Re: Choosing Ruby on Rails for web development project in 2019

#111

Post by andrei_says_ »

cpursley wrote: post #100

I love Ruby/Rails and owe my career to it, but I don't see the advantage of choosing this stack in 2019 over Elixir/Phoenix for greenfield projects. Elixir tooling and libraries are now up to par and I'd argue have surpassed RoR. At this point, it's just as productive (perhaps even more as you don't have to glue on a bunch of additional components) and joyful to work with like RoR but massively scalable out of the bo…

I’ve been considering Phoenix and looked at Elixir which made me realize how much I love Ruby. So I am starting my new Rails project and loving every second of it.

Re: Choosing Ruby on Rails for web development project in 2019

#112

Post by conanbatt »

jasim wrote: post #85
conanbatt wrote: post #50

Earlier quoted context omitted.

I have to be honest, I don't understand why people care so much about typed languages. I almost never face type related issues, and when they occur they are the easiest to catch.

Passing a string where you expect a number is not the only kind of type errors modern type systems are about. They can catch a particular class of domain-level bugs, and more importantly, it acts as a pair programmer who tells us about all the logical edge cases that we forgot to think about, as we program. This is done using what is called "sum types" - we can tell the compiler that say a user can be "Premium" or "R…

> ...We now have to hunt and peck across the codebase, and change all our policies so that it handles this possibility well.

A stellar case about Object design, not strong typing. I don't find type solves this issue, in fact, it even might be the opposite. Its way looser and more flexible to be able to say how things actually behave than to define the exact type they are to see how they behave.

The static analysis is definitely a huge plus, but it's a bit tangential: if a static analysis tool were able to point to the same issues, the reason would evaporate. (It's like saying a language is better because it has a better community, which is practical but not intrinsic).

Re: Choosing Ruby on Rails for web development project in 2019

#113

Post by andrei_says_ »

sbov wrote: post #6

> Great for CPU-intensive tasks. Ruby is among the slowest languages out there. Which is fine for most webapps, but calling it great for CPU intensive tasks... I don't understand what logic is being used to come to this conclusion.

When I get half a million users I’ll start worrying about it. Most startups fold way beyond this point. Saving dev time and the pleasure and ease of working with Ruby more than make up for the speed difference.

Re: Choosing Ruby on Rails for web development project in 2019

#114

Post by conanbatt »

save_ferris wrote: post #92
conanbatt wrote: post #50

Earlier quoted context omitted.

I have to be honest, I don't understand why people care so much about typed languages. I almost never face type related issues, and when they occur they are the easiest to catch.

Type-related issues are super common in rails apps with several contributors. Do you ever get "undefined method foo for nil:NilClass"? That's a type error. There isn't really a universal agreement on how to handle nil in the ruby community, and as long as that remains true, type issues will continue to be a daily reality of using the language.

I don't find nil errors to be as cumbersome as the over-design required to type everything you do.

Re: Choosing Ruby on Rails for web development project in 2019

#115

Post by theptip »

87zuhjkas wrote: post #71
mipmap04 wrote: post #60

Earlier quoted context omitted.

I've taken the approach of building the monolith first with an architecture that allows me to easily pull parts of it out into services when I hit constraints and need that scalability.

How?

If you push to keep your code organized into modules with simple function APIs, and make sure that code outside your modules doesn't use the package internals directly, then your function APIs can be easily extracted into a REST/gRPC call, and the only thing that changes (to the first approximation) is your internal service (function) calls become external service (api) calls.

Obviously you now need to add an API client layer but in terms of code organization, if your packages are cleanly separated then you've done a lot of the work already. (Transactions being the obvious piece that you'll often have to rethink when crossing a service boundary).

The advantage of this approach is that it's much easier to refactor your internal "services" when they are just packages, than it is to refactor microservices after you've extracted them and set them free (since upgrading microservice APIs requires more coordination and you can't upgrade clients and servers all in one go, as you often can inside the same codebase).

Re: Choosing Ruby on Rails for web development project in 2019

#116

Post by JohnBooty »

Dangeranger wrote: post #79
vinceguidry wrote: post #64

Earlier quoted context omitted.

As a counterpoint, I love ActiveRecord. It's a Swiss Army knife that's got pretty much everything you need, you just need to find the right tool and use it. What ActiveRecord isn't is discoverable . Which is to an extent understandable. Its domain is literally anything you could express in SQL. But you really can do anything you want with it, you just have to find the right abstraction. A tool I use a lot is to .to_s…

Long ago I liked ActiveRecord(AR), then I worked at a company that did large aggregations in SQL and found it to be severely limited in working with complex queries which use many JOIN statement and sub-queries. During that time I came to enjoy working with the Sequel[0] gem, and its fantastic documentation. Now, after working with Ecto[1] in Elixir, I've found that the ROM[2] builder pattern is a better approach to…

From what I've seen of Sequel is looks awesome and I've been dying for an excuse to use it.

    found [ActiveRecord] to be severely limited in 
    working with complex queries which use many 
    JOIN statement and sub-queries
I'd humbly suggest that this is not a flaw of ActiveRecord whatsoever! I think this is AR working exactly as designed.

I would certainly agree that SQL > AR once your queries grow past a certain (fairly low) complexity threshold.

But, AR (wisely) doesn't try to be a complete replacement for SQL. It very happily (and even elegantly, I might say?) lets you use raw SQL pretty much any time you, the developer, feel it's more convenient/productive. That principle is pretty explicitly baked into AR.

Many ORM frameworks don't make this easy at all, whereas with AR it's very painless.

I have a lot of beef with AR but I think this is one of its strong points.

Re: Choosing Ruby on Rails for web development project in 2019

#117

Post by yebyen »

chrisseaton wrote: post #30
yebyen wrote: post #27

Earlier quoted context omitted.

Yes, it's there, you can enable it, but I haven't heard anyone recommend it for production use, and it's not enabled by default. I tested it myself, it seemed to make my boring use case a little bit faster, once the JIT cache is initialized.

> it seemed to make my boring use case a little bit faster That's an unusual result - if it's faster for an actual app you're using in production you should report that as they'll be thrilled.

If you can call it that... my site is actually a Jekyll blog, in development mode, this is running in the most needlessly Ruby way. (A production deployment would have pre-rendered all the pages, and there wouldn't be a need to have a Ruby process even be present on the running server.)

Each visitor hits a Ruby process which renders the page directly, or serves it up from filesystem cache. I'm not honestly sure which, it could be monitoring the filesystem for changes to the markdown files, and only recompiling them when it observes a change on disk... or it could be rendering each request freshly for the visitor.

It would be hard-pressed to call this a production deployment though, I can say without a blog post or any hard data to back it up that when I did side-by-side trials, the page loading response times were marginally faster with the JIT enabled, after repeated trials.

After watching @tenderlove's talk from RailsConf 2019, I think I'm obligated to say also about this that, your results will improve if you paid attention to cache hit ratios, and consider tuning the JIT Cache size to achieve the maximum benefit. Perhaps these things will be better in a later iteration of Ruby JIT?

Re: Choosing Ruby on Rails for web development project in 2019

#118

Post by wry_discontent »

cpursley wrote: post #100

I love Ruby/Rails and owe my career to it, but I don't see the advantage of choosing this stack in 2019 over Elixir/Phoenix for greenfield projects. Elixir tooling and libraries are now up to par and I'd argue have surpassed RoR. At this point, it's just as productive (perhaps even more as you don't have to glue on a bunch of additional components) and joyful to work with like RoR but massively scalable out of the bo…

Maybe I'm biased, but I recently relearned rails (having done one project in it about 6 years ago) and found it much easier to pick up than Elixir/Phoenix, despite liking Phoenix quite a bit.

Re: Choosing Ruby on Rails for web development project in 2019

#119

Post by jaegerpicker »

csolorio wrote: post #101
jaegerpicker wrote: post #37

I think I'd only ever choose RoR for a throwaway project, in 2019. I do love RoR and the development experience but Elixir and Phoenix give me almost exactly the same feeling but with WAY better performance and an Immutable/Functional language that results in much cleaner and better code. It's an investment to learn Elixir but it's 100% worth it and honestly I'd choose Phoenix over Rails almost every time.

What is your IDE setup? I like elixir, but it seems that IDE support isn't where I'm used to in other languages. Specifically module auto imports/aliasing. Not a big gripe, but I haven't found an IDE I like as much as Rubymine for Elixir.

We mainly use VS Code with the ESElixir plugin but I've had great luck with Intellij Idea and the Elixir plugin also.

Re: Choosing Ruby on Rails for web development project in 2019

#120

Post by kickopotomus »

quest88 wrote: post #76
conanbatt wrote: post #50

Earlier quoted context omitted.

I have to be honest, I don't understand why people care so much about typed languages. I almost never face type related issues, and when they occur they are the easiest to catch.

How many team members contribute to your codebase? I've personally found that I need it less when it's just me committing code, but need it at my large company when traversing unknown codebases.

Even when its just me, if I leave a project for >1 month and then try to come back and pick up where I left off, I have a much easier time getting back up to speed with a typed language vs un/dynamically typed.
Post reply on HN