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

Ruby on Rails: The Documentary [video]

youtube.com

Post reply on HN
Print view View original

171–180 of 248 posts

Re: Ruby on Rails: The Documentary [video]

#171

Post by kennethwolters »

tinco wrote: post #145
Pmop wrote: post #105

Earlier quoted context omitted.

Not "any" but "most". I've worked for a company whose RoR codebase/structure looked completely different from the usual because they used a Domain Driven Design-inspired architecture.

This is due to a conflict of philosophies within the RoR community. Basically the clean code enthusiasts (which are also more likely to subscribe to DDD) argue that business logic should not be tied to which specific web application framework you use. So it should basically be in a separate codebase, either in the `lib/` directory or literally in a different project and included into your application as a Gem. This m…

That's very interesting! In Django this "Rails Engines" approach is the default. A Django project will be made out of multiple Django "apps", each having its own routers (called URL-dispatchers), controllers (called views - yes, I know its weird to call them that), models and templates.

Re: Ruby on Rails: The Documentary [video]

#172

Post by Glyptodon »

game_the0ry wrote: post #73

I tried to like ruby and rails, but when I tried to grok the language, I found it more difficult to follow than python + js (my daily drivers). Did anyone else feel the same way? I kind of want to give it another chance bc I have some side projects that I want to try out, but I find django/python and next/react easier to grok. Maybe I should try harder? FWIW, I also want to pick up good practices when it comes to eng…

Ruby is much more straightforward than Python or JS IMO. But Ruby devs tend to love metaprogramming a lot more (IMO) which can seem obtuse.

Re: Ruby on Rails: The Documentary [video]

#173

Post by ksec »

berkes wrote: post #17

> if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. I used to love this, untill I started to hate it. I am convinced this is a major contributor to why so many Rails apps turn into an unmaintainable mess over years. Who measures onboarding in hours? It's fine if it takes a day or two to understand the domain. And the framework. An…

>Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck.

I mean you could have at least picked some better example. Considering Rails was precisely extracted out from Basecamp which is "Domain. Team and Project Planning".

Re: Ruby on Rails: The Documentary [video]

#174

Post by jasonwatkinspdx »

brap wrote: post #9
mosselman wrote: post #2

I had a lot of fun watching this documentary. The one person framework really comes out in the personal story of Toby from Shopify. "From Hello World to IPO". What I also loved is that he mentioned that if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. Sure that can be true for many apps, but in a world of, for example, APIs and f…

>if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one I've never worked with Rails, but this sounds amazing. One of the things I really hate about the Node.js ecosystem is that there are no clear conventions, the structure is always different even when the same framework is used. It's a mess. The exception is probably Next.js but it's…

It's a huge benefit for agency/consultant work. You can jump into a project you've never seen before and just know where everything is and how it's wired together. You can be immediately productive.

The downside is if you want to do something that cuts "across the grain" so to speak, things can get messy. Combine that with Ruby's high dynamism and someone trying to be too clever can make a mess fast (alias_method_chain anyone?).

Yeah, node has been incredibly successful but I think it's a fair criticism to say it's also a victim of that success in that it just feels like so much arbitrary complexity. And the flavor of the month changes so fast that projects end up this weird mishmash.

Re: Ruby on Rails: The Documentary [video]

#175

Post by neonsunset »

kaba0 wrote: post #151
DoesntMatter22 wrote: post #34

Earlier quoted context omitted.

Is there a comparable framework that does what Rails does but is somehow 10x faster? I wouldn't use Rails for everything but the fact that plenty of companies like Shopify are serving millions of requests per second with it shows that it's probably acceptably fast for mega scale apps.

Spring, perhaps.

Cumbersome build and deployment, and high level of ceremony alone prevent it from being a sufficiently competitive choice.

Re: Ruby on Rails: The Documentary [video]

#176

Post by ksec »

DoesntMatter22 wrote: post #34
jupp0r wrote: post #20

Earlier quoted context omitted.

I couldn't agree more. There is also a technology aspect to it. Rails is objectively veeeeeery slow. Concurrency support is nonexistent. This is not a good fit for all problems. It also to some degree prevents you from breaking out the parts that would benefit from a different language into their own services (Rails needs to call them, but it's really not good at IO).

Is there a comparable framework that does what Rails does but is somehow 10x faster? I wouldn't use Rails for everything but the fact that plenty of companies like Shopify are serving millions of requests per second with it shows that it's probably acceptably fast for mega scale apps.

Spring and ASP.NET.

Re: Ruby on Rails: The Documentary [video]

#177

Post by theonething »

SkyPuncher wrote: post #61
magicmicah85 wrote: post #54

Going to have to watch this later today. I've messed with so many frameworks in the past - Laravel, ExpressJS, MeteorJS, Django, Flask, etc. All of them have their benefits and drawbacks and I've been at different knowledge levels when I've tried them all but I've always tried tutorials, done my own thing and given up. Three days ago I started using rails and I just flew through the weekend to get a MVP setup to show…

I've been a Rails dev for a long time. I've tried a bunch of things and keep coming back to it for the same reasons as you. I'm incredibly productive in it. For the longest time, my primary complaint has been a lack of documentation/conflicting information when you break from convention. It can be extremely challenging to find/understand the "blessed" way of doing things. Thankfully, ChatGPT is extremely good at prov…

Could you give an example of how ChatGPT helped you specifically with Rails?

Re: Ruby on Rails: The Documentary [video]

#178

Post by ericb »

jupp0r wrote: post #91
gv83 wrote: post #70

Earlier quoted context omitted.

you're seriously convinced they would have had no problems if they chose something else? every codebase that lasts that long and is used that much is going to face very hard challenges as it scales and meets new landmarks. the maintainable codebase from day 1 to day 5000 is (mostly) a myth. yeah maybe some other stack could have faced different tradeoffs. I'm also curious about YOUR choice of stack at this point.

I never said that some other stack wouldn't have problems. My point was that Rails is great at some problems and awful at others. No idea how this can be controversial at all. My impression seems to be that there is a group of fanboys that are not able to have any intelligent conversation on what their favorite tool is good for and what it's not good for. In my day job I use mostly Rails. My team is starting to rewri…

> My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for.

What sort of web app do you have that is CPU bound?

Re: Ruby on Rails: The Documentary [video]

#179

Post by mokkol »

rbates wrote: post #111
HalcyonicStorm wrote: post #8

Earlier quoted context omitted.

I'm always here to speak praises for Ryan Bates. His practical videos to build features was a huge insight for me as a junior developer at the time.

Thanks! Glad to help.

Thanks Ryan. You made me love Rails and to be passionate about coding. I’m still working every day in it and still love it every single day. I have a one man SaaS that is providing for me and my family for the last 9 years.

You played a big part in it. Thank you!

Re: Ruby on Rails: The Documentary [video]

#180

Post by jasonwatkinspdx »

JohnBooty wrote: post #161
berkes wrote: post #17

> if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. I used to love this, untill I started to hate it. I am convinced this is a major contributor to why so many Rails apps turn into an unmaintainable mess over years. Who measures onboarding in hours? It's fine if it takes a day or two to understand the domain. And the framework. An…

I am convinced this is a major contributor to why so many Rails apps turn into an unmaintainable mess over years. I have two easy answers to why Rails apps turn into messes. 1. Any non-trivial app in any non-trivial language/framework usually becomes a mess eventually, given enough commits and developers 2. Rails (specifically, ActiveRecord) won't stop you from creating circular dependencies between models. This is e…

> You're right of course: that's a one-time cost.

I disagree. This presumes that there's some initial "onboarding" process, and that once that's done you just now will know the structure of the app for all future, never spending more effort on it.

That's only true for trivial apps. What actually happens in bigger codebases is after you stop working in some section of the code for a few weeks, it falls back out of your head and you have to figure it out again. Additionally, without conventions other members of your team are constantly inventing new structures and connections between things.

So really this lack of consistent organization is a continuous drag, not a one time cost.

Post reply on HN