[HN Gopher] Ruby on Rails: The Documentary [video]
___________________________________________________________________
Ruby on Rails: The Documentary [video]
Author : 541
Score : 373 points
Date : 2023-11-13 09:18 UTC (13 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| mosselman wrote:
| 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 front-end stacks, that
| isn't always the case.
|
| The latest developments in Rails are making the solid foundation
| even more solid. There is stuff happening to make infrastructure
| easier: Kamal sure, but also Solid Cache and Solid Queue and
| there is a lot happening in the front-end with Turbo (Morphing)
| and mobile apps with Turbo Native and Strada.
|
| We have upgrade to 7.1 already and have a mobile app in
| production that is built with Turbo Native. I am also excited to
| start replacing our Redis cache with Solid Cache to make
| everything simpler and cached longer.
|
| Great to see the Rails community so alive and see the deep
| connection the (ex) core team members have to the framework!
| brap wrote:
| >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 more frontend-y.
| Towaway69 wrote:
| 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
| dkdbejwi383 wrote:
| > P.S. Perhaps because a JS framework based off the ideas
| of rails would be called jails! /s
|
| https://sailsjs.com/
| monooso wrote:
| Laravel would be a better example for PHP, especially as it
| borrowed so many ideas from Rails.
| pocketsand wrote:
| Correct.
| AlchemistCamp wrote:
| I agree. The only frameworks I've found about as
| productive as Rails are Laravel and Phoenix.
|
| Django and Sails.js both seemed like they were a step
| down in terms of general productivity, though each had a
| unique advantage of their own (admin out of the box,
| websockets & realtime features).
|
| I haven't had a chance to really give RedwoodJS a trial
| run, but it's the JS-based fullstack framework I'm most
| curious about.
| kugelblitz wrote:
| After a few years, and as my own application has grown, I
| feel I'm more productive in Symfony than Laravel, because
| there's less magic, I know where stuff is, and it's more
| "loosely" coupled components whilst Laravel is "All in or
| get out". I've been updating my app since Symfony 3.3-ish
| to now 6.3 and it's been fun! I've had to exchange the
| auth, the admin section, added new features, killed off
| features, but I feel with time, that my code has gotten
| more stable.
|
| Maybe my first update experience with Laravel was a bit
| of a mess (v4.2 to v5.0 "The recommended method of
| upgrading is to create a new Laravel 5.0 install and then
| to copy your 4.2 site's unique application files into the
| new application. This would include controllers, routes,
| Eloquent models, Artisan commands, assets, and other code
| specific to your application."), and I couldn't easily
| "see" the models' properties and the Facades, that's why
| I have shy-ed away from it a bit. I have worked with
| several Laravel applications since then and have gone
| through the v6 through v10 upgrade cycle and can say it's
| gotten easier (though I wish they could settle on a
| release schedule), but my preference is still Symfony.
|
| Plus when I checked out Django, I felt a bit more "at
| home" (e.g. see Twig templating language and how they
| used Django templating language as inspiration).
|
| I've worked with Vue.js and AngularJS 1 and Angular 2+,
| but I'm glad htmx is coming in strong, so I can focus on
| logic, speed and stability instead of glueing the
| frontend and backend API together and debugging in the
| different browsers.
| kaba0 wrote:
| It will probably not be a well-liked comment, but Spring
| is absolutely there in terms of productivity, and the
| cool thing about it is that it never leaves your side
| when it comes to more and more complex requirements. It
| really has everything and especially Spring Data with JPA
| is unbeatable.
| riffraff wrote:
| Wouldn't python's _the framework_ be Django?
| noirscape wrote:
| 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.
| pier25 wrote:
| I've wondered about this for years.
|
| Express was the default with Node for some years but it was
| mostly used for APIs to feed front ends. These days lots of
| people have switched to Fastify but again mostly for APIs.
|
| There's really nothing fullstack in the JS world that can
| be compared to Rails, Laravel, or Django.
|
| Current fullstack solutions (Next, Nuxt, SvelteKit, etc) in
| JS are trying to kludge front end components into the
| server which IMO is a mistake. And I say this as someone
| who has been doing mostly front end since the 90s.
| joshmanders wrote:
| > There's really nothing fullstack in the JS world that
| can be compared to Rails, Laravel, or Django.
|
| I would like to introduce you to Adonis.
| https://adonisjs.com
| pier25 wrote:
| It's cool. Another similar option is Platformatic by the
| creator of Fastify.
|
| https://platformatic.dev/
|
| But still... There are no queues or jobs. No HTML over
| the wire. No colocation of presentation logic. Etc.
| joshmanders wrote:
| All of that stuff can be easily added using 3rd party
| packages, just like Laravel, Rails, Django, etc all have
| userland addons. https://packages.adonisjs.com
| Towaway69 wrote:
| > to kludge front end components into the server which
| IMO is
|
| I think you make a good point here, JS is uniquely able
| to be executed both frontend and backend, hence things
| such as underscore templates.
|
| Other languages don't have that ability. Therefore I
| would agree that there is no point in making a 1to1 copy
| of existing MVC ideas.
|
| Being an ex-rubyist and now doing a lot of NodeJS, I
| really enjoy moving server code to the client at zero
| mental cost since it's mostly the same APIs
| pier25 wrote:
| Sharing code is cool but OTOH the back and front end are
| two completely different beasts.
|
| Trying to use client patterns to solve the server has
| been mostly a mistake. OTOH separating server and client
| and using an API to glue has produced a lot of issues too
| (SPAs, etc).
|
| I think the future is a hybrid model where 80-90% of the
| front end is orchestrated from the server (LiveWire,
| Hotwire, LiveViews, etc) and 10-20% is a pure client side
| solution.
| chpmrc wrote:
| I've built Django projects for years and wondered the same
| thing whenever I had to build something in Javascript land.
| There are some scaffolding tools that do pretty much what
| those frameworks do (e.g. create.t3.gg, which I've used
| recently for a couple of small projects and really liked)
| but obviously lack that feeling of cohesion that strong
| opinionated frameworks like Rails or Django come with.
|
| Not sure if that's a plus or a minus, after all there might
| be devs whose preferred stacks differ by 1 or 2 items (e.g.
| prisma over drizzle, nextauth over something else) and
| they'd both benefit from having a standardized template to
| start with.
|
| EDIT: just remembered I fell in love with Meteor for a
| while. Then they started shoving React and other external
| stuff into it to gain more market share and it inevitably
| lost that opinionanted nature that, IMO, made it so good.
| Choice isn't always a good thing for the end user (even,
| and sometimes especially, when that end user is a
| professional who just wants to get things done).
| reducesuffering wrote:
| Despite what others will say here, it actually is Next.js.
| People don't agree with parts of the stack (just as C#/Java
| people didn't agree with what Rails was doing in 2005), or
| point out projects with the equivalent mindshare of
| Sinatra/Flask like Nuxt and Svelte, but when you look at
| what company-level projects are majority building with in
| 2023, it's Next.js.
|
| https://insights.stackoverflow.com/trends?tags=next.js%2Cne
| s...
| bdcravens wrote:
| Many of the Node projects (typically Express) I've built
| start out super tiny, one or two files, but once they grow to
| any production-level complexity, I find myself more or less
| mirroring the Rails structure.
| Pmop wrote:
| 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.
| danmaz74 wrote:
| I really liked the DDD book, but I think that many of the
| suggestions mostly apply to huge "do it all" enterprise
| applications, which are also not the best fit for Rails. So
| I think it's OK if you can't easily apply those patterns to
| a Rails app - if you actually need to build a single
| enterprise application to rule them all, you should
| probably choose a different framework anyway.
| tinco wrote:
| 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 makes sense from an objective perspective on what
| constitutes clean code, and I used to believe that this is
| what a really large enterprise Rails codebase should be
| refactored to eventually (although I never personally did
| so).
|
| Rails offers an alternative approach to this however, that
| is less neat from an objective perspective, but actually
| follows the Rails principles a lot better and it's called
| Rails engines. Basically you split your Rails app up into
| multiple mini-rails apps for each domain called Rails
| engines, each has the same directory structure as a Rails
| app and you get the full benefits of a regular Rails app
| inside each. I used to think this was an ugly approach and
| I never even considered it, but now after over a decade of
| Rails development I've made a 180 and I believe this is the
| way to go.
|
| The "clean" way forces you to construct interfaces between
| your business logic and the Rails app, basically
| introducing a lot of extra boiler plate. All for the
| perceived benefit of making your business logic be abstract
| of the Rails framework. This violates YAGNI of course, and
| by a huge margin too. I've never seen the business logic of
| a Rails app be ported to some other framework in 15 years,
| the most I've seen is reusing code in a Grape API that was
| mounted inside the Rails app. And what you give up is
| Rails' convention over configuration and its predictable
| structure, and the general documentation and knowledge of
| that structure that people can carry from job to job.
| kennethwolters wrote:
| 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.
| berkes wrote:
| > 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. And how
| they tie together.
|
| Talking about the domain: Rails puts "the plumbing" up front.
| Its how it achieves this consistency. My app is never about
| "models" or "http" or "databases". My app is about medicine-
| journals. Or loan-request-management. Or CRM. Rails makes
| itself important, at the cost of my domain.
|
| Rails' opinionatedness makes it so that this is hewn in stone.
| Its MVC is a given - and that's fine - major architectures
| should probably be dictated by the framework. But it's ORM -
| ActiveRecord also is a given. And that's not fine because AR
| (as an architecture and as how Rails implements it) is very
| unfit for a large category of applications. It's virtually
| impossible to swap AR out for anything else. Same with
| templates/views, JS, Caching, and many more: you can -in
| theory- replace them with a drop-in alternative. But you cannot
| -not even in theory- replace them with something that has an
| entirely different architecture or concept. This makes Rails
| not Omakase, but actually McDonalds: wherever in the world you
| come, you know exeactly what to expect, but it also makes
| boring and bland: no-one eats 7days/week McD.
|
| This makes all Rails apps look alike. Despite the fact that not
| one of the apps that "we" are building is alike another.
| Domain. Team. Project Planning. Combine any of them and the
| projects demand different things, but with Rails you are out of
| luck. Regardless if you build the next fintech platform with a
| team of 120 senior devs over 6 years, or you hack your
| "marketplace for coffeelovers" over the weekends alone: you get
| The Rails Way. One of those might be a perfect fit. But it's
| impossible they all are. Each team gets the same "menu". And in
| many cases it simply won't fit.
| jupp0r wrote:
| 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).
| DoesntMatter22 wrote:
| 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.
| claudiug wrote:
| and gitlab, github :)
| jupp0r wrote:
| 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.
| AlchemistCamp wrote:
| I'm sure things have changed post-acquisition, but for a
| very long time Github's back-end languages were just Ruby
| and C.
| jupp0r wrote:
| Turns out C is better at some problems than Ruby after
| all? This was my point.
| AlchemistCamp wrote:
| Agreed on that. My point was just that even at massive
| scale, the vast majority of the backend was written in
| Ruby.
| jupp0r wrote:
| Rails does everything. You can build a stateless API
| gateway with it. Is it great for that particular use
| case? No. Your question about frameworks with similar
| capabilities is pointless because my point was that there
| are use cases where the capabilities of Rails are not a
| good fit.
| DoesntMatter22 wrote:
| You said it's objectively very slow. My question is
| relevant because your point begs the question: Slow
| compared to what?
|
| If you want to give an honest apples to apples comparison
| then, okay fine, what framework that does everything that
| rails does is considerably faster?
|
| Is a Ferarri faster than a dump truck? Sure, but they
| have different uses. Try hauling gravel with a Ferrari.
| For the class that Rails is in, there isn't anything as
| feature compatible that is also an order of magnitude
| faster.
| andrewmutz wrote:
| 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.
| DoesntMatter22 wrote:
| Except when you look at benchmarks it's actually not that
| much faster than rails.
|
| https://www.techempower.com/benchmarks/#section=data-r21&
| hw=...
| andrewmutz wrote:
| I don't know how they measure it, but other measurements
| have shown different results:
|
| https://medium.com/@elviovicosa/phoenix-vs-rails-
| benchmark-2...
| nickjj wrote:
| > I don't know how they measure it, but other
| measurements have shown different results
|
| The big difference is the blog post you linked performs a
| very basic GET request to an endpoint. It mentions it
| doesn't hit the database or deal with caching. It's
| basically a non-realistic hello world that is good at
| isolating performance of a specific library but doesn't
| show how it fits into the grand scheme of things.
|
| The other link performs multiple database queries as part
| of the request which goes back to the old saying that for
| a huge portion of web apps you're I/O bound (AKA waiting
| for something else such as the database).
| kaba0 wrote:
| Spring, perhaps.
| claudiug wrote:
| compare with what, in what load?
| jupp0r wrote:
| 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.
| jakswa wrote:
| 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.
| jupp0r wrote:
| 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.
| matt_s wrote:
| You're bike shedding [0].
|
| Rails/DHH took already established design patterns and made
| strong opinions into a convention on the folder hierarchy of
| where you store your code. You can change that hierarchy, its
| not set in stone. It will require a lot of change. I've been
| on teams and it isn't just on-boarding time, its countless
| hours trying to find code written by someone no longer there
| that had their own layout of where files should go. Without
| conventions, people will run amok with a file structure.
| Multiply that by the number of developers on the team with
| attrition and different view points on organizing files and
| it can be a giant mess after a number of years. Its all a
| waste of time and has nothing to do with the quality of the
| code, what domain the application is in or anything really.
|
| If you love Ruby there are other libraries out there like
| Sinatra [1] that don't have the conventions of Rails.
|
| [0] https://en.wikipedia.org/wiki/Law_of_triviality
|
| [1] https://sinatrarb.com/
| yawboakye wrote:
| i'm preparing a talk for either railsconf or railsworld that
| puts this question/concern to the community. two times i have
| deviated from the standard apps/{models,controllers,views}
| layout and i have profited massively, especially in terms of
| conceptual integrity and abstraction. all my code lives in
| app/lib under domain-specific directories. this includes the
| models. the only part worth separating is the web router and
| controllers. i have achieved separation between my app and
| the web parts that aren't offered by default by rails. i'm
| hoping to share my experience, for the community's
| consideration.
| berkes wrote:
| I've had the pleasure to work on such kinds of Rails apps a
| few times. It was almost magical, compared to all the other
| common Rails apps with their ever accumulating fat models,
| complex controllers, untestable- coupled classes and so on.
|
| One had this what you describe: everything in /lib, and the
| MVC merely delegating to that. MVC downgraded to what it
| should be: plumbing that binds together your domain stuff.
|
| The other did something similar but had it in gems (bound
| as Railties/engines). IT was a bit more cumbersome, as one
| had to release a new gem before being able to integrate it
| in the rails app. It forced a very solid separation of
| concerns.
| cies wrote:
| > compared to all the other common Rails apps with their
| ever accumulating fat models, complex controllers
|
| i interpret fat model as: what can be move to the model,
| sits better in the model (directory). things that cannot
| be moved to the model: the request, the response, the
| session. not set in stone, but usually this works.
|
| what i regret about older Rails code i wrote was the
| gluing of all biz logic to ActiveRecord ORM models (akin
| to, yuck, Hibernate entities), that also contain DOAs,
| form validation and all business logic. now i tend to
| split these out: form dtos that do validation, repos with
| queries, simple record classes, etc.
|
| fat signals homogenous big thing, but is actually where
| most of the application lives. i coudl call it lib as
| well.
| andrei_says_ wrote:
| In one of her interviews Sandi Metz mentioned that she
| separates all her activerecord models under models/ar.
|
| She is big on separating the business logic from the
| framework.
| treis wrote:
| IMHO if you're splitting an app into domains you might as
| well go all the way and split it into an engine or gem.
| yawboakye wrote:
| i doubt. the further down the wedge drives the harder it
| gets to make the components communicate, and i think when
| communication gets hard we've probably gone too far.
| that's not even taking into consideration the mechanisms
| of managing engines/gems.
| larksimian wrote:
| 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 where to put every file in a project or having to
| invent a new folder structure for every app we build fills me
| with a bizarre mixture of boredom and rage.
|
| As with everything in life the people that whine about the
| medicine the most are the ones that make it necessary.
| berkes wrote:
| > You're building CRUD apps.
|
| No. "we" are not.
| parthdesai wrote:
| > Domain. Team. Project Planning. Combine any of them and
| the projects demand different things, but with Rails you
| are out of luck
|
| hmm, sounds like this rails app that one might have not
| heard bout. You should check it out. Think it's called
| Basecamp
| emmet wrote:
| help I've just witnessed a murder
| PH95VuimJjqBqy wrote:
| on the off chance someone doesn't understand the subtext
| here.
|
| BaseCamp is DHH's company's product. DHH is the creator
| of Ruby on Rails. He literally create RoR to build
| BaseCamp, which is exactly the type of software the other
| poster is claiming is problematic for RoR.
|
| DHH is on record as having said RoR was evolved
| organically from the early code of BaseCamp.
| jupp0r wrote:
| 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.
| mosselman wrote:
| 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.
| jupp0r wrote:
| Totally, Rails is a great tool. So is my gunsmith hammer.
| I can like it for what it does without arguing it's the
| best thing in the world for cutting wood or joining two
| pieces of metal together.
| gv83 wrote:
| 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.
| jupp0r wrote:
| 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
| 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. Rails was great to get started fast.
|
| Nothing wrong with using a press instead of a hammer at
| some point, they are just tools.
| arnvald wrote:
| Is there any comparably complete framework that does not
| need any significant adjustments even when it's used by
| 1000s of developers building the same app?
| jen20 wrote:
| Probably ASP.NET is as close as it gets.
| neonsunset wrote:
| This, it is also on the other end of performance
| spectrum.
| kaba0 wrote:
| Or its Java counterpart, Spring.
| jen20 wrote:
| I think that's a bit unkind to ASP.NET ;-)
|
| But yes, Spring and the various Java equivalents probably
| also fit the bill.
| seattle_spring wrote:
| Can confirm. Nothing worse than figuring out what sort of
| "magic" is affecting a route in a huge Rails app. Oh
| look, a before_filter in a super class 4 levels up that
| is defined in an include helper. But wait, why isn't it
| affecting all calls and only some? Ah there's another
| chain of filters that you only can know about if you are
| familiar with the older Rails version API.
|
| Rails is the "goto:" label of web frameworks. It's
| unbelievable how much it encourages spaghetti code and
| misdirection directly via its conventions.
| breakfastduck wrote:
| 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.
| ativzzz wrote:
| At the end of the day, all programming is CRUD at various
| levels of abstraction. You read some data, and then
| create/update/delete various forms of related data in
| various locations, like your DBMS or maybe a file or your
| GPU's VRAM
|
| Rails provides a way to approach CRUD via MVC.
| Controllers are your API. Models are the connection to
| the Database. Views are what the controllers render.
|
| If your app doesn't do these 3 things - API, Database,
| and representation of your API - you don't need rails (I
| bet you do those three things). Other than that, you're
| free to layer on whatever architecture via ruby that you
| want on top of these basic rails constructs. If you don't
| like it, again don't use rails. It's opinionated for a
| reason
| butlike wrote:
| Then I think the focus should be on the API. At
| enterprise level, the API becomes the language, and the
| frameworks (and even departments to an extent) become the
| functions/methods.
|
| Business = program
|
| Company = class (business can be a conglomerate)
|
| Department = method
|
| frameworks = implementation details
| butlike wrote:
| I don't think it's necessarily bike shedding, and actually
| a lot of the sentiments resonated with me. Rails is a tool
| that does a tool's job. It's nice to know a hammer does
| hammer things when you're expecting it. If you need a
| level, maybe use a different tool. I think the main issue
| is everyone expecting it to be "one-size fits all." It was
| never meant to be that, really
| DoesntMatter22 wrote:
| I don't know what exactly the complaint is here. You don't
| like that Rails has a common structure?
|
| > It's virtually impossible to swap AR out for anything else.
|
| I've used Mongo and a number of other ORM's, why can you not
| use other ORM's exactly?
|
| This just sounds like you don't like frameworks and want to
| build things from the ground up, because most of the
| complaints you make are just not true. Maybe you are just
| inexperienced with Rails because you can swap out almost
| anything.
| PH95VuimJjqBqy wrote:
| because behavior is an unspoken part of contracts.
|
| I can't reasonably swap out an array with a linked list
| even if the official contracts are the same.
|
| this is why things like DAL's are created, they give you an
| opportunity to deal with the differences in behavior.
|
| The issue with frameworks like RoR that use AR throughout
| is that the queries are sprinkled throughout the codebase,
| giving no opportunity to fix such behavioral differences.
|
| What happens is every ORM then attempts some sort of "query
| reuse" and they do so badly because it's not possible to do
| it well with the contracts they expose. It creates code
| where you can't ever reason about the query that's actually
| being generated.
| LargeWu wrote:
| What kinds of queries are sprinkled throughout that are
| not part of AR, or depend on AR?
|
| Sure, if you are going to swap out AR for another ORM in
| the middle of an established project you are going to
| have a bad time, but if one is doing that I have larger
| questions.
| PH95VuimJjqBqy wrote:
| I must be misunderstanding the question because anything
| that queries in rails uses AR and that's often done in
| both lib code and controller code rather than behind a
| dedicated module boundary.
|
| What is it that's not making sense to you?
| DoesntMatter22 wrote:
| > because anything that queries in rails uses AR and
| that's often done in both lib code and controller code
|
| How is that different from any other framework ever? You
| have to query the DB somewhere. Rails makes it incredibly
| easy to swap out databases. Much more so than any other
| platform I can think of.
|
| Nothing is making you use AR at all. This is a non issue.
| gv83 wrote:
| since "plumbing" is an essential part of *every* application,
| I'd rather not focus on it all the time.
|
| I maintained both kinds of framework-heavy and "organic home
| grown just libraries" apps, and you know what? I totally
| prefer framework heavy stuff; at least it has battle tested
| facilities for everything, and I can expect consistency
| instead of fomo-driven/resume-driven development.
|
| my last homegrown framework was a nasty 60k LoC api that did
| like 10 operations. total business logic was 3000 lines,
| including fn declarations and docs. just transaction scripts.
| the remaining 57k were a gargantuan amount of boilerplate
| that gave absolutely nothing to the project, and all in
| "typed python" which is like 0.9x java verbosity. a massive
| piece of shit.
| manicennui wrote:
| The key is to build a Ruby app and then provide HTTP access
| and persistence using Rails. You can find a lot of articles
| about this by searching for Rails and hexagonal architecture.
|
| My biggest issue with trying to do this is ActiveRecord. I'd
| much prefer the repository pattern.
| JohnBooty wrote:
| 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 easy
| to avoid, but it doesn't warn you about this or try to
| prevent it. So 99% of Rails apps have like, a User model that
| depends on (and is depended on by) most of the other models.
| This is far from a Rails- or ActiveRecord-specific issue
| though. Who measures onboarding in hours?
|
| You're right of course: that's a one-time cost. It's nice to
| optimize this but as you say, it's a one-time cost. Assuming
| a developer will spend multiple months or years working on
| the app, it would be better to optimize for the rest of that
| time.
|
| However I think the standardization on MVC pays off here as
| well. For apps with multiple developer teams you may
| constantly be "onboarding" as you move between different
| areas of the app. And you can move forward with less
| bikeshedding. And that's not fine because
| AR (as an architecture and as how Rails implements
| it) is very unfit for a large category of
| applications
|
| I agree, although I also feel strongly that AR is very good
| at getting out of the way and letting you just use raw SQL
| when you want.
|
| So IMO/IME it works well for scenarios where some of your
| data is AR/ORM friendly and some isn't.
| Same with templates/views, JS, Caching, and many
| more: you can -in theory- replace them with a drop-
| in alternative
|
| I can't agree. A lot of Rails projects use HAML instead of
| ERB and while I never set that up myself, I wasn't under the
| impression that it was a hassle.
|
| Rails' caching backend has been seamless to swap between DB,
| Redis, in-process, and Memcached backends. As far as the
| caching "frontend", it's entirely optional, so I can't really
| imagine there is an obstacle to swapping it for something
| else? Like, you never _have_ to use `Rails.cache`.
|
| As for the JS side of things, I don't think I totally agree.
| There aren't drop-in alternatives, but you don't have to use
| Stimulus, and you can certainly use your own.
| This makes all Rails apps look alike.
|
| This is good in a lot of ways. Less bikeshedding more
| building. But, also... I have to admit. I am bored to tears
| with Rails. Happy to be working in another language/framework
| for the moment and possibly forever.
| merelysounds wrote:
| > so many Rails apps turn into an unmaintainable mess over
| years
|
| Does this happen more often for Rails than for other
| frameworks?
|
| There are many ways in which a Rails project can get
| derailed. But they seem not different from regular tech debt
| and I could imagine equivalent problems in other
| environments.
|
| > AR (as an architecture and as how Rails implements it) is
| very unfit for a large category of applications
|
| If you plan to build an application belonging to a category
| where AR is not a good fit, why use Rails?
|
| I wouldn't claim that Rails is a good fit for all problems.
| Still, I'd say the structure and defaults of Rails are one of
| its strong benefits.
|
| Or do you mean "application" as in "usage" - i.e. that over
| time you might notice a problem that's hard to solve with AR?
| Could you give an example? I'd guess you could use a
| different approach for a single task, or even move from Rails
| to a different tool if that becomes a big issue.
| ksec wrote:
| And lots more.
|
| Ruby 3.3 YJIT is 2x faster than Ruby 2.5 in RailsBench.
|
| Work on brining more Ruby Gem from C to Ruby ( easier JIT )
|
| Lots of dev tooling around Ruby and Rails coming.
|
| Hopefully there are more good things to come in Rails 8.0 and
| Ruby 3.4
| DoesntMatter22 wrote:
| What's funny to me is I have been doing Rails for 15 years,
| even wrote books on it, and I just thought Tobi was a guy who
| made a lot of popular Rails stuff. Didn't realize he was the
| founder and worth 5.5 billion dollars lol
| bbx wrote:
| > "From Hello World to IPO"
|
| Which specific documentary is it? Google seems to return a few
| different options.
| bdcravens wrote:
| The linked Youtube video.
| bbx wrote:
| Ah yes, around 41 min in... Thanks for the reply.
| southwesterly wrote:
| So if I have an idea for an online service / app. I can go an
| make it using Ruby on Rails all on my lonesome?
|
| Do I have to deal with JavaScript in any way?
| cooljacob204 wrote:
| > I can go an make it using Ruby on Rails all on my lonesome
|
| Sure can. However I won't pretend it's the only framework you
| can do this with and be productive. I love Rails and Ruby but
| it has great competitors these days.
|
| > Do I have to deal with JavaScript in any way?
|
| Really depends on what you're doing but probably.
| bluedino wrote:
| The structure of Rails was my first experience of web
| development (as a job, at least) and it completely ruined me
| for anything else.
| PH95VuimJjqBqy wrote:
| I'm going to have go push back on this.
|
| I don't like the RoR community, not because they're bad people,
| but because I think they're insane from a tech perspective.
|
| I only occasionally pick up RoR work because of how off-putting
| my first experience was. But what makes it worse is that every
| project I've been on (including one I just started on a few
| weeks ago) has just been a cluster.
|
| What you're saying here is true in theory, but what you're not
| telling people is how the community is about as close to the
| attitude of npm as you can get on the server side. hundreds of
| gems on your typical application, many of which are used in 1
| or 2 places, helping avoid a grand total of less than 5 lines
| of code.
|
| Then there's the ratwheel you opt into with rails. Every single
| damned time I find myself having to manually patch libraries to
| get it working properly. I even once had to track down an old
| Ubuntu image of a version that had EoL'd 5 years prior and THEN
| had to manually patch a few C dependencies just to get it to
| build and run.
|
| Don't even get me started on wkhtmltopdf, fuck that dependency.
| If you use that in your RoR project, fuck you.
|
| ^ that's only partially meant to be humourous.
|
| My experience is that developers suggest RoR then run off into
| the sunset on their new project, leaving companies not
| understanding that they're now on a ratwheel of maintenance and
| upgrades until it's so bad only someone such as myself even has
| the skillset necessary to pick up the pieces.
|
| Contrast this with asp.net core. Each LTS version is supported
| for 2 years (which is too short imo), but more importantly, you
| can install the EOL versions just fine. I would never recommend
| RoR over asp.net core (asp.net 6+ ... LTS only) because
| developer productivity isn't worth the maintenance cost.
| neonsunset wrote:
| .NET's LTS releases are supported for 3 years and STS are
| supported for 18 months. I wish LTS support was 5 years, it
| seems like ecosystem has matured enough post-going-OSS-wild-
| ride starting with .NET 6 release and is ready for such a
| support timeframe. Or at least they could have every other
| LTS be ELTS?
|
| Also, I do wonder if RoRs perceived productivity is by
| inertia? I have a hard time believing you can top the
| productivity of quick scaffolding for back-end you get circa
| .NET7-8?
| PH95VuimJjqBqy wrote:
| you're right, looking closer I got my wires crossed.
|
| non-LTS is 2 years, LTS is 3 years
|
| https://dotnet.microsoft.com/en-
| us/platform/support/policy/d...
|
| imo, short term RoR will beat the pants off asp.net core in
| terms of developer productivity. mid to long term asp.net
| core wins hands down in terms of developer productivity.
|
| I don't think the RoR productivity story is fake, but I do
| think it's not worth the long term maintenance costs.
| evntdrvn wrote:
| On the flip side, within the last few years, upgrading .NET
| versions has become typically a very easy exercise.
|
| The ASP.NET team tends to churn stuff wayyy more often than
| I'd like for questionable reasons, which can make keeping
| more painful than I'd like - but tbh I often just keep
| using the older ways of doing things in ASP.NET since it's
| almost always still supported...
| block_dagger wrote:
| I think you have encountered some projects built by
| undisciplined teams. That is not a reflection on the
| framework, rather a reflection on the people improperly using
| it.
| PH95VuimJjqBqy wrote:
| while that's true and obviously you can avoid these
| problems with any framework with enough discipline, my
| point is that the community in general isn't disciplined.
|
| I've repeatedly seen the same things over a 15+ year
| timespan.
| mattgreenrocks wrote:
| The culture encourages a lack of discipline; indeed, high
| framework coupling is seen as the Rails way.
| mattgreenrocks wrote:
| Perfect storm of dynamic typing, needing to keep up with
| breaking changes, thought leaders that thought leader too
| much, and a community that seems to push back on anything
| that calls into question The True Rails Way.
| JohnBooty wrote:
| it looks basically the same in structure whether it is the
| biggest Rails app there is or a new one
|
| Totally agree! Developers tend to really undervalue this aspect
| of RoR.
|
| In addition to easier onboarding, it greatly reduces
| bikeshedding.
|
| MVC maybe isn't the best paradigm for everything, but it's good
| enough for most things.
| qudat wrote:
| > 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
|
| Which is funny because uncle bob cites this as a major downside
| to architecting code.
| Andugal wrote:
| Honeypot documentaries are really good ! I highly recommend them.
| dorianmariefr wrote:
| Watched it and loved it
| Towaway69 wrote:
| Two figures that inspired me were missing, why the lucky stiff
| and Ryan Bates from railcasts fame.
|
| Otherwise great docu with DHH "f*uk you" slide which does give an
| insight into successful open source projects.
| brightball wrote:
| Ryan Bates is a legend
| Towaway69 wrote:
| Ryan did so much for the rails community and all because of
| the joy for RoR.
|
| Unfortunately iirc Ryan suffered a burnout and had a lengthy
| break. I hope all that is better now.
| rbates wrote:
| All is better. I still plan to blog about the burnout.
| Towaway69 wrote:
| Great to hear and please blog about it - folks need to be
| aware of the dangers of burnout.
|
| Unfortunately having folks around me that had burnout
| helped me to avoid one myself.
| TheRealDunkirk wrote:
| Indeed. Also, kudos to Chris Oliver for taking up the mantle.
| https://github.com/excid3
| brightball wrote:
| I think he heard us...
|
| https://news.ycombinator.com/item?id=38253485
| HalcyonicStorm wrote:
| 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.
| rbates wrote:
| Thanks! Glad to help.
| kawsper wrote:
| I agree with that, I would also have liked to have seen
| Tenderlove in it.
| Towaway69 wrote:
| Yes! Tenderlove was brilliant, especially his profile image
| :)
| VeejayRampay wrote:
| tenderlove is legend, on both the Ruby and the Ruby on Rails
| sides
| rbates wrote:
| I wouldn't expect to be mentioned in the documentary, but
| thanks for the shout out. :)
| aczerepinski wrote:
| Well done. One thing that struck me is how young the framework is
| in the big scheme of things. When I first got into programming
| around 10 years ago, people were already writing articles about
| how Rails was near obsolete so without giving it much thought I
| assumed it was from... maybe the early 90s?
| AlchemistCamp wrote:
| One of my biggest mistakes as a dev was not really learning Rails
| until 2015.
|
| I just didn't know how much faster building web apps could be.
| CPLX wrote:
| Yeah me too. I am still sad thinking about the number of hours
| I spend messing with python environments and versions because I
| was told it was the "quick and easy" option for solving this or
| that small problem.*
|
| Also worth mentioning Michael Hart's intro course, which is a
| really shockingly well done way to ramp up from absolute zero,
| even for someone with very little code experience.
|
| * Which, in fairness, it mostly is. But also meh.
| silent_cal wrote:
| Were you using Django?
| AlchemistCamp wrote:
| His book is what got me up to speed in 2015. I was visiting
| Chiang Mai and binged through the whole thing over a few days
| and then spent the next week cloning various personal
| projects I'd written with JS backends.
|
| In under two weeks of opening Michael Hartl's _Rails
| Tutorial_ , I was already more productive with RoR than with
| the stack I'd been using professionally for 3+ years.
| MatthiasPortzel wrote:
| Same. I spent so long building Django apps and trying to solve
| problems that StackOverflow told me were inherently difficult,
| only to find out that Rails has built-in solutions.
|
| This isn't even a criticism of Django; the things that Django
| does, it does very well. But there are a lot of things that it
| doesn't do that a mature web app will eventually need to
| handle.
| windowshopping wrote:
| My biggest issue with rails is that the convention it forces
| you into feels like it's not really a one-size-fits-all
| solution. I typically build sites that are a one-page or 2-3
| page JS app running on an API, as opposed to the more
| traditional idea of backend paths that return html views. And
| it seemed like rails wasn't well-suited to that, which was
| why I didn't stick with it.
| hnarayanan wrote:
| This was so fun to watch. It's great to see people find their
| calling and do great work and change the world for the better
| along the way.
| Alifatisk wrote:
| Sounds like from the comments that Rails is gaining a little bit
| more popularity again instead of being known as the boring robust
| framework
| lagniappe wrote:
| 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.
| DoesntMatter22 wrote:
| After doing lots of Node and Go I've recently come back to
| Rails and, no joke, it's about 5x faster in development for
| me. So many niceties. Using Prisma I had a 25 line method
| (and no real models) and that went down to 3 lines in Rails.
| It's just a night and day difference. I won't leave Rails
| again.
| swlkr wrote:
| Rails really is the premiere framework for web development
| speed
| Alifatisk wrote:
| I couldn't have said it better, its impressive how much you
| are able to do through Rails in such a short time.
| Vayl wrote:
| Why wouldn't you use it again and what would you use instead?
| mplewis wrote:
| 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.
| whitepoplar wrote:
| Which of DHH's technical decisions would you consider
| poor?
| 0xferruccio wrote:
| Really amazing documentary! Been using Rails for the last couple
| of years and it's just so productive for a small team to build
| product and follow well established patterns in building business
| logic.
|
| I'd recommend to those interested in seeing how a real Rails app
| is structured to look at the Jumpstart codebase as it's a great
| resource on how to structure things
|
| https://jumpstartrails.com/
|
| As an alternative Bullet Train is pretty good, even though it
| adds a lot of bespoke libraries that aren't the "Rails way"
|
| https://bullettrain.co/
| adrianlmm wrote:
| I saw it and I don't think it make it any justice, Ruby on Rails
| changed the paradigm of creating web applications with routes
| instead of files (like PHP, JSP and Webforms did) with the MVC
| pattern that now is present in every respectable web framework
| and the documentary doesn't tell that. It was enjoyable though.
| steve1977 wrote:
| MVC was already used in frameworks like WebObjects for example
| (and maybe others) quite a while before Ruby on Rails was born.
| cooljacob204 wrote:
| Sure but I think the point is Rails popularized it.
| stevoski wrote:
| Struts was a popular Java MVC framework in the early 2000's and
| was pre-Rails.
|
| I kind of feel bad mentioning Struts and Rails in the same
| sentence, though, as Rails did much more than Struts.
| cromulent wrote:
| I do seem to remember DHH complaining about "XML pushups"
| when Rails was released, and knowing what he meant from
| Struts.
| lagniappe wrote:
| sad to see _why the lucky stiff left out, but I suppose it is
| what he'd have wanted.
| chris_st wrote:
| Don't remember _why doing any Rails development -- he was
| really key in Ruby land, but did his own (super-minimal) web
| thing called Camping. Anything I'm forgetting that he did
| with/for Rails?
| vario wrote:
| his 'artsyness' was the main reason I avoided learning Ruby for
| years-- wrongly thinking people who code in Ruby speak like
| him.
|
| I know this is a possibly unpopular opinion but I don't think
| one should glorify a sophomoric book as a key Ruby book-- there
| are others that deserve that title, PickAxe is close, but I'd
| have liked a book like Whittaker's "C#, Player Guide" for Ruby.
| sleight42 wrote:
| Perhaps Ruby isn't for you then?
|
| Matz's intent was and has been to bring joy and delight to
| developers, with the odd combination of PERL, LISP, and
| Smalltalk as his inspirations. Joy and delight don't
| necessarily equate with "most practical". But joy and delight
| are wonderful and healthful qualities to cultivate for a good
| life!
|
| _why embodied much of the spirit of the (at least earlier)
| Ruby community. We were software developer immigrants, many
| coming from prescriptive verbose technologies (I'm looking at
| you, Java!). We were eager for novel ways of expressing our
| ideas. Ruby's metaprogramming capabilities are, as far as I
| know, still all but unmatched beyond perhaps Smalltalk itself
| (and IO, which AFAIK no one uses seriously). _why's
| playfulness captured all of this in elegant and sometimes
| bizarre but often artistic expressions in his projects and
| code.
|
| I will _never_ regret or apologize for the Ruby community 's
| appreciation for the Poignant Guide.
|
| And, _why, wherever you are and whoever you are, thanks.
| vario wrote:
| Typical deficit in reading comprehension is the hallmark of
| the mediocre mind.
| lagniappe wrote:
| > Typical deficit in reading comprehension is the
| hallmark of the mediocre mind.
|
| Are you insulting the person who responded to your
| comment?
| qup wrote:
| only if he's multi accounting
| sleight42 wrote:
| I'm sorry you feel that way.
|
| Sure, Ruby is for anyone who wants to use it.
| Deradon wrote:
| There was not really a place to put it into the rails doc. But
| I put a comic strip as a tribute to _why into a related blog
| post: https://cult.honeypot.io/reads/why-ruby-on-rails-is-not-
| dead...
| LeonidBugaev wrote:
| What I really appreciate about Rails, is the strong vision, and
| not becoming another bloated framework for building "enterprise
| grade" applications. This is a 20-year-old framework, which does
| not afraid to radically change with time, and still being seen as
| Punk compared to rest
|
| It was so heartwarming to remember my Rails story, its been 20
| years ago since I started using it!
| https://twitter.com/buger/status/1723040883325460818
| dmix wrote:
| Funny they show pictures of Berlin overlayed with "Toronto" at
| @22:16, I guess they meant to say Tobias moved from
| Germany->Canada but it made me ???.
| bewuethr wrote:
| And in the shot before that, Chicago!
| siva7 wrote:
| There are so many legends from the early rails days that paved
| the way to how we develop modern web apps. I would go as far to
| say that in web development there is a time before and after
| rails emerged.
| magicmicah85 wrote:
| 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 a coworker. Rails just made it
| easy to focus on what my app needs to do, not how my app needs to
| be implemented. I can finally see why people love it so much.
| SkyPuncher wrote:
| 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.
| impish9208 wrote:
| Dupe: https://news.ycombinator.com/item?id=38222535
| emmet wrote:
| Haven't touched rails in several years, but now I need to get an
| idea to get back into it!
| game_the0ry wrote:
| 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
| engineering a back end, and the good ex-rails engineers I know
| tend to be really good in general.
| brightball wrote:
| When I first started with Rails on a project I took over in
| 2012 I really disliked it.
|
| Today it's something I repeatedly try to tell everybody about.
| It's just so productive.
| samtechie wrote:
| Interestingly, for me it is the exact opposite, I tried
| Django/Python and it's more difficult for me to grok. Somehow I
| just find Rails easier and more straightforward.
| game_the0ry wrote:
| I think its bc I just know python better. When I look at ruby
| code, especially with symbols, I can't really tell what's
| going on the same way I can with python. I get the impression
| python is more simple while ruby is more powerful
| (featurefull) + more object oriented.
| qup wrote:
| I've worked more in Python, but rails was way more intuitive
| for me than Django. I knew just how I should do everything,
| and if I needed to alter some functionality, I knew just
| where to look. I loved its consistency.
|
| I like ruby quite a lot, too.
|
| rails made me very fast.
| rc_hackernews wrote:
| This was (is) me.
|
| Love Rails, but found it very difficult to learn Ruby. It's
| very hard for me to read, but that may be because I come from a
| C# background.
|
| If you're looking for something like Rails, I'd recommend
| trying out Laravel.
|
| It's on par with Rails as far as features, ease of use, etc.
| And PHP was a lot easier to learn for me versus Ruby.
| spaceywilly wrote:
| Honestly, if you only are familiar with Python, it's gonna be
| pretty tough to learn anything else. I would recommend spending
| some time learning literally any other language (Ruby is fine).
| Otherwise, if you just know Python, I think it will hold you
| back.
|
| For example, ending an if statement with semicolon and then
| having the if block indented below is just not the normal way
| to do things. I'm not knocking Python, I use it all the time
| and it's great, but it's not a language you can carry over to
| learning other languages. It's like if you know English, it's
| pretty easy to learn Spanish. But if you only know Chinese,
| it's going to be tougher to learn an "English-ish" language.
| Hope that makes sense.
| game_the0ry wrote:
| FWIW, I have experience in TS/JS, Python, Java, and Scala. I
| would say TS/JS is my strongest stack.
|
| Its not the minor syntax differences that I have trouble
| with, its that ruby does not "fit my brain like a glove."
| block_dagger wrote:
| Look at https://dry-rb.org/, some of the patterns there may
| seem more familiar.
| Glyptodon wrote:
| 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.
| scop wrote:
| I'm a longtime PHP/JS dev who recently decided to give Ruby and
| Rails a look given its influence on Laravel. The first thing I
| did was read the Rails Doctrine and, while I appreciated most of
| it, I thought "The Principle of The Bigger Smile" and DHH's
| comments re Ruby's elegance were one self-indulgent-bridge too
| far. Back to the jaded PHP cave I go...
|
| That was until I learned that in Ruby:
|
| `someObj.some_var = 'hello'`
|
| Is syntactic sugar for:
|
| `someObj.some_var=('hello')`
|
| That made me smile. I have never smiled like that about a
| programming language. It literally gave me _joy_.
|
| I'll be honest I have some trepidation devoting my time now to
| something "old", but on the flip side my career is in PHP so what
| the hell am I talking about "old" for.
| corytheboyd wrote:
| You're going to love writing tests for Ruby! Nearly everything
| is a message send, which works insanely well with testing
| libraries. It's so damn easy and clean to reach meaningful test
| coverage in Ruby where it feels like a chore in other languages
| dividedbyzero wrote:
| I remember fondly when RoR was the hottest thing, so elegant and
| easy to understand, but I haven't touched it in ages. Is it still
| good compared to the more up-to-date stuff? Is it still relevant?
| block_dagger wrote:
| Absolutely! I switched from PHP to Rails in 2008 and I've been
| able to upgrade all of the relevant projects to modern 7.1.
| Lots of changes/maturation along the way, but all in the right
| direction. Still best web framework for fast prototyping in
| 2023. I use Rails every day. Not the best for high concurrency
| or system tasks, but great for expressing maintainable business
| logic and working on web apps in teams.
| sigzero wrote:
| They was a really good watch. The gentlemen in the video were and
| are very passionate about Rails.
| timetraveller26 wrote:
| By now I have watched many programming documentaries by Honeypot
| and I can't recommend them enough. They have documentaries of ue,
| React, GraphQL, Ember and some more.
| battery_glasses wrote:
| I worked on a very large production rails app from 2015-2019 and
| came away loving Rails and hating Ruby. Give me Rails in TS or Go
| and I couldn't think of any reason to ever use anything else for
| a web app backend.
|
| The Rails Console has to be one of the greatest productivity
| enhancers I've ever come across.
| corytheboyd wrote:
| I'd love to see a Go REPL that can do nearly as many things as
| you can do with a Ruby REPL. It's just not really possible I
| think. It could be doable with TS with the existing node REPL,
| but Ruby really is a huge driver behind why Rails console is as
| useful as it is.
___________________________________________________________________
(page generated 2023-11-13 23:00 UTC)