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

61–70 of 248 posts

Re: Ruby on Rails: The Documentary [video]

#61

Post by SkyPuncher »

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 providing a starting point for this stuff.

Re: Ruby on Rails: The Documentary [video]

#62

Post by noirscape »

riffraff wrote: post #56
Towaway69 wrote: post #12

Earlier quoted context omitted.

True, nodejs really doesn't have _the_ framework. Python had flask, php is WordPress and RoR. Why is that? Especially since most of the new frameworks copy the ideas of existing frameworks. P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s

Wouldn't python's _the framework_ be Django?

Yeah for a default rigidness with the ability to tinker in obvious ways the framework for python is imo Django.

Flask is almost completely freeform in what it allows you to do, it just has a few style recommendations and a ton of community convention, but you could technically ignore 90% of it since Flask doesn't really expect any sort of structure.

Re: Ruby on Rails: The Documentary [video]

#63

Post by jupp0r »

AlchemistCamp wrote: post #58
jupp0r wrote: post #45

Earlier quoted context omitted.

These two have lots of backend code that's not Ruby. Rails is great at what it does and it's not optimal for many other use cases.

I'm sure things have changed post-acquisition, but for a very long time Github's back-end languages were just Ruby and C.

Turns out C is better at some problems than Ruby after all? This was my point.

Re: Ruby on Rails: The Documentary [video]

#64

Post by mplewis »

Vayl wrote: post #50
lagniappe wrote: post #31

Earlier quoted context omitted.

I probably won't use it again in any projects, but I liked the video because of nostalgia. Rails is a memory of a fun and scrappier me, a different time, appropriate in its own light for my path at the time.

Why wouldn't you use it again and what would you use instead?

Governance seems more invested in making ideological changes (dropping Webpacker, TypeScript, breaking changes between versions that add busywork but no value) than building the community and expanding reach. DHH continues to push poor technical decisions and alienate contributors by taking weird political stands.

As someone who’s taken multiple projects to production in Rails and generally loves Ruby, these days I prefer to start new projects in full-stack TypeScript. RedwoodJS has been quite good.

Re: Ruby on Rails: The Documentary [video]

#65

Post by jakswa »

jupp0r wrote: post #48
claudiug wrote: post #36

Earlier quoted context omitted.

compare with what, in what load?

From my day job: Stateless API gateway making HTTP calls to other services, which have response times in seconds for various reasons. Rails throughput ~20 requests per second. Golang rewrite throughput: 200k requests per second. Same hardware.

I helped write what might be a similar API gateway prototype in rails (made a DB query and decorated downstream requests with auth/role/etc headers). You might have threadpool/process/concurrency tuning to do. Even then, I don't think rails is a good solution for what is essentially an HTTP proxy, and I would've pushed for a different tool if time wasn't an issue. Rails was fast to build, I'll give it that. We ended up getting downstream service to $1M ARR so rails wins out against my "let me write it in XYZ language/framework" again somehow.

Re: Ruby on Rails: The Documentary [video]

#66

Post by andrewmutz »

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.

Phoenix framework on elixir does come close to this. Designed by people with a background in ruby and rails, and has much of the same design philosophy.

That said, there are areas where Phoenix can't match rails, such as having access to a large developer community and a large existing base of libraries.

Re: Ruby on Rails: The Documentary [video]

#67

Post by jupp0r »

jakswa wrote: post #65
jupp0r wrote: post #48

Earlier quoted context omitted.

From my day job: Stateless API gateway making HTTP calls to other services, which have response times in seconds for various reasons. Rails throughput ~20 requests per second. Golang rewrite throughput: 200k requests per second. Same hardware.

I helped write what might be a similar API gateway prototype in rails (made a DB query and decorated downstream requests with auth/role/etc headers). You might have threadpool/process/concurrency tuning to do. Even then, I don't think rails is a good solution for what is essentially an HTTP proxy, and I would've pushed for a different tool if time wasn't an issue. Rails was fast to build, I'll give it that. We ended…

This is the point I wanted to make. Rails is great for some problems, not great at others. I can tell you for example that it's not great at transforming 2MB of JSON into a differently structured 2MB of JSON.

Re: Ruby on Rails: The Documentary [video]

#68

Post by mosselman »

jupp0r wrote: post #53
larksimian wrote: post #30

Earlier quoted context omitted.

You're building CRUD apps. The conventions work and are extensible for teams of 1, 10, 100 and 1000s. You are not special and neither is your product. Companies making millions or billions of dollars have used this framework successfully. This level of bike-shedding is what makes conventions necessary especially when dealing with the typical hyper-pedantic software developer. Just the thought of having to debate wher…

Your model of companies using Rails with 1000s of engineers is almost comically naive. Look at what Shopify and Github have to do to make Rails work for them. Also look at the non Ruby code engineers there are writing and ask yourself why they might be doing it. Rails is not a religion. It can be good at what it does without having to go on a crusade when people point out its substantial limitations.

If your reverse your comment you could say “only when your reach 100s of developers will you need to start changing things a bit.”

Sounds good to me. Most companies never reach that scale and if they do, I think investing into some extras will be well worth it.

Tobi looks pretty chill about it in the documentary.

Re: Ruby on Rails: The Documentary [video]

#69

Post by breakfastduck »

larksimian wrote: post #30
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…

You're building CRUD apps. The conventions work and are extensible for teams of 1, 10, 100 and 1000s. You are not special and neither is your product. Companies making millions or billions of dollars have used this framework successfully. This level of bike-shedding is what makes conventions necessary especially when dealing with the typical hyper-pedantic software developer. Just the thought of having to debate wher…

This is part of the problem with your claim - many of us are not building CRUD apps, we are building complex enterprise software and there are unique challenges to solve.

Re: Ruby on Rails: The Documentary [video]

#70

Post by gv83 »

jupp0r wrote: post #53
larksimian wrote: post #30

Earlier quoted context omitted.

You're building CRUD apps. The conventions work and are extensible for teams of 1, 10, 100 and 1000s. You are not special and neither is your product. Companies making millions or billions of dollars have used this framework successfully. This level of bike-shedding is what makes conventions necessary especially when dealing with the typical hyper-pedantic software developer. Just the thought of having to debate wher…

Your model of companies using Rails with 1000s of engineers is almost comically naive. Look at what Shopify and Github have to do to make Rails work for them. Also look at the non Ruby code engineers there are writing and ask yourself why they might be doing it. Rails is not a religion. It can be good at what it does without having to go on a crusade when people point out its substantial limitations.

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.

Post reply on HN