[HN Gopher] What's New in Ruby on Rails 8
___________________________________________________________________
What's New in Ruby on Rails 8
Author : amalinovic
Score : 429 points
Date : 2024-10-07 14:45 UTC (8 hours ago)
(HTM) web link (blog.appsignal.com)
(TXT) w3m dump (blog.appsignal.com)
| faizshah wrote:
| I highly recommend you watch the first half hour of DHH Rails
| World talk on Rails 8 even if you aren't a Ruby dev:
| https://youtu.be/-cEn_83zRFw?si=ANVPRory_J0LKjZj
|
| The idea of Rails 8 is to move away from trend following and try
| to reject some of the ideas that have become popular in the
| industry (like being afraid to touch a Linux server or
| implementing your own auth). Really though provoking stuff.
| galoisscobi wrote:
| I second this. I'm not a ruby dev and I watched the whole talk.
| It was excellent.
|
| Goes on to show how for many applications overly priced
| platforms as a service aren't really needed but incidental
| complexity masquerading as essential complexity is peddled as a
| way to make money.
| xutopia wrote:
| This is part of the reason why I love the Rails community so
| much. It isn't afraid to break down the consensus and find its
| own path forward. Often with huge benefits.
| rubyfan wrote:
| Popular ideas are exactly the problem in the industry. I've
| been really put off by what I believe is a lack of critical and
| original thinking in tech. Bad leadership within management,
| cult and fad following seems to abound.
| mattgreenrocks wrote:
| There's a real feeling of the blind leading the blind in
| webdev.
|
| htmx, Rails, and Laravel all point to better ways, and people
| are starting to be receptive.
| hello_moto wrote:
| It's DHH marketing style (it sez right there in his earlier
| book: pick a fight).
|
| Back when Rails burst into the scene, he picked the EJB
| mountain to battle and positioned Rails vs EJB for as long as
| he could.
|
| This is another battle in the Infrastructure world that he
| picked.
|
| The timing was perfect too: Rails grew during economy crisis
| 2006-2009 (layoff, EJB complexity, web-app complexity, the rise
| of single-developer entrepreneur). Right now we're sort of in
| similar situation too: layoffs, infrastructure complexity,
| BigTech culture, FAANG-leetcode grind.
|
| Tech is like a cycle :)
| gadders wrote:
| >>It's DHH marketing style (it sez right there in his earlier
| book: pick a fight).
|
| I think rappers invented starting a beef to shift records.
| MangoCoffee wrote:
| >try to reject some of the ideas that have become popular in
| the industry
|
| just my two cents, the web development has become akin to the
| fashion industry.
|
| We've seen a steady stream of frameworks emerge, from
| traditional PHP and JavaScript to JavaScript-based development
| like ReactJS, AngularJS, and now WebAssembly while tried-and-
| true methods still work.
|
| all the new frameworks bring benefits - but also introduce
| problems a few years later. The trends drive the IT industry,
| fueling a cycle of book sales, training camps, and consulting
| services that corporations buy into every few years.
| IWeldMelons wrote:
| cant wait when we'll start making webdev in C CGI and finally
| in Verilog.
| wiseowise wrote:
| > JavaScript-based development like ReactJS, AngularJS
|
| React is 11 years old, AngularJS is 14 years ago, let it go
| already, gramps.
| Thaxll wrote:
| His compagny seems to like re-inventing the wheel with vastly
| inferior solutions though.
| pier25 wrote:
| I don't know about Rails but Kamal 2 is pretty great.
|
| It's their own E2E solution for deploying and running Docker
| apps in production. Solves SSL, proxy, zero downtime deploys,
| etc.
|
| https://kamal-deploy.org/
| jack_riminton wrote:
| Example?
| mplewis wrote:
| Kamal, Thruster, removing TypeScript from Rails without
| notice, moving into Webpack and back out again without a
| reasonable upgrade path, pushing Hotwire over real
| frontends.
| Lukas_Skywalker wrote:
| Does ,,removing TypeScript from Rails without notice"
| refer to the conversion of Turbo from TS to JS from a
| year ago?
|
| They changed the implementation of an optional library.
| The interface of the library didn't change at all. Only
| how it was implemented.
| software_writer wrote:
| For a concise overview of all the new frameworks and
| announcements, I recommend reading the official Rails blog post
| from DHH:
|
| https://rubyonrails.org/2024/9/27/rails-8-beta1-no-paas-requ...
| rgbrgb wrote:
| yeah, OP feels like a gpt rewrite of this post by DHH
| joshmlewis wrote:
| Agreed, this should be the main link instead of giving
| AppSignal free publicity. The original is very much a light
| reworking of the original. It has the same content order and
| everything.
| noobermin wrote:
| People just don't talk about Ruby anymore. For those who don't do
| webdev, has it just stabilised and people take it for granted
| now, or was it always hype and people have long since moved on?
| mostlysimilar wrote:
| Both Ruby and Rails have continued to improve year over year
| and are better today than they have ever been.
| rogerrogerr wrote:
| I've worked on many Rails apps that are still out there in
| critical spots. My gut feel is it has stabilized. The hype was
| well-founded; it allows dev velocity that I still haven't seen
| in any other environment.
|
| I once worked on the integration of an existing Rails app into
| an existing C# webapp (both living side-by-side, kind of a
| split-application thing, but seamless to the end user). It was
| almost hilarious how many LOC the C# teams (!) were having to
| write for every LOC I (alone) was writing in Rails. Looking
| through their diffs, it seemed like they were reinventing fire
| compared to me writing `render :success if
| SomeModel.update(model_params)`.
| neonsunset wrote:
| It speaks more about the unfortunate state of practice in the
| team in question. C# itself is of similar terseness when
| compared to Ruby, with 10x to 20x better performance so even
| when written in a bulkier way, it becomes less relevant as
| you are not going to hold, say, C or C++ against similar
| criticism in such context. Oh, also no method not found thing
| too. C# has much greater likelihood of _not_ having defects
| when you do deploy it.
| frostymarvelous wrote:
| I'd say this speaks more to the metaprogramming
| capabilities of rails rather than the team itself.
|
| Rails simply does more for you out the box with just a few
| macros.
| neonsunset wrote:
| Do you have a specific example in mind?
| pantulis wrote:
| I think what parent said is referring to stuff like
|
| https://github.com/mbleigh/acts-as-taggable-on
|
| It's not only that RoR comes with a complete toolset --
| it allows you to create your own libraries that extend
| the capabilities of the framework while keeping the
| developer experience terse enough through metaprogramming
| (compare the sample code in the README with the file
| acts-as-taggable-on/lib/acts-as-taggable-on/taggable.rb,
| where you can see how the library is opening the classes
| in runtime through the class_eval technique.
|
| I'm sure something similar can be achieved in C# but not
| so sure about the elegance of the result.
| neonsunset wrote:
| I read through the description. Funnily enough, it's a
| second time I ask a question "what does Ruby have?" and
| the response provides something very specific to Ruby
| that does not idiomatically translate to other languages
| in a way that someone in polyglot environment would
| immediately understand a need for.
|
| Statically typed languages usually have other, better
| ways, to associate metadata with the types, if necessary.
| Or avoid having such a requirement at all.
|
| > For instance, in a social network, a user might have
| tags that are called skills, interests, sports, and more.
| There is no real way to differentiate between tags and so
| an implementation of this type is not possible with acts
| as taggable on steroids.
|
| Isn't that's just having a property/field on a
| struct/class/type/object that contains the list of tags?
| Active Records seem to be effectively EF Core's tracked
| entities but with seemingly more "magic" under the hood
| (something that ORMs are often criticized for, including
| catching undeserved strays by EFC).
|
| In general, I remain very negative towards Ruby and Ruby
| on Rails because most feedback that I hear leaves an
| impression of "so it has some of the advantages similar
| to top modern web frameworks in C# and Java/Kotlin but
| with a huge bag of breakage risk with codebase growth, a
| need to extensively cover code with tests and static
| analysis to cover for mistakes that are impossible in
| statically typed languages, and one tenth of performance
| on a sunny day".
|
| Now, I don't think it's a bad choice in a vacuum, but
| it's important to consider the overall experience and
| practices used in a language A vs B, and whether either
| is used correctly.
| Tainnor wrote:
| As someone who started his career writing Ruby (but has
| since migrated to statically typed languages), I agree
| with your criticism. One big problem I had with the Rails
| community was the overemphasis on libraries/frameworks
| that make the code superficially look nice ("just put
| this dependency in your Gemfile, and it will
| _automagically_ work ") but aren't actually well-designed
| enough to be composable. The moment you're gonna have to
| do something out of the happy path, you're often out of
| luck.
|
| The tagging problem in particular isn't such a hard
| problem that you' should need to pull in an extra
| dependency just for that. It's basically just a nested
| set of hash maps, the "hardest" part about it is the
| persistence - and I do believe it's worth spending maybe
| 2 hours on a proper DB schema in exchange for having code
| you own and understand.
|
| There are other libraries in the Ruby ecosystem that take
| different approaches (dry.rb for example, which IMHO,
| strikes a better balance between the expressivity of Ruby
| and solid design), but they're not all that popular.
| Lukas_Skywalker wrote:
| > Isn't that's just having a property/field on a
| struct/class/type/object that contains the list of tags?
|
| I have never used the library, but it seems you get a lot
| more with just 2-3 lines of configuration (e.g. for a tag
| context named ,,interests"):
|
| - The ability to find the n most or least used tags with
| a single method call - The ability to track which user
| tagged a record - The ability to find records with the
| same tags - Calculation of tag statistics for a tag cloud
|
| Now, all that would certainly be possible with EF. But
| many libraries for Rails give developers a very simple
| way to configure a feature, and deliver very expressive
| methods to use the feature. Which is an important
| property imo, since it often makes obvious what the code
| does, even for newcomers.
|
| This is probably an effect from Ruby itself, where the
| standard library is quite expansive and has many often-
| used patterns built in. For example, calculating an
| arrays maximum value is just arr =
| [1,2,3,4] arr.max
|
| Meanwhile, in JS: arr = [1,2,3,4]
| let max = arr[0]; for (let i = 1; i < arr.length;
| i++) { if (arr[i] > max) max = arr[i];
| }
|
| And to address the README of the above library: I think
| it is a bit confusing because it starts with a comparison
| with another library, expecting readers to already know
| how tagging worked there.
| wiseowise wrote:
| > C# itself is of similar terseness when compared to Ruby,
| with 10x to 20x better performance so even when written in
| a bulkier way
|
| More like 50-100x.
| neonsunset wrote:
| It is true and you have to lack technical knowledge to
| downvote this.
|
| In regular "line of business" code this difference might
| be a bit difficult to see in between the calls waiting
| for DB and third-party dependencies, so I went with more
| conservative numbers. On the more complex code this
| difference will be totally observable.
| brink wrote:
| Rails usage is certainly dropping off a bit. The competition is
| improving.
|
| I personally got tired of the monkey patching, ActiveRecord's
| proclivity towards n+1 queries, and complete lack of types /
| static analysis, among other things. Having to keep a mental
| model of the types of the entire project, and having to write
| tests around types takes up a significant amount of my
| headspace, energy, and time. The older a project gets, the more
| of a headache these things become. There is an element of "just
| write better code" to avoid these pitfalls, and that works to
| an extent, but the older I get the more I realize that the
| tooling does play a large role in the outcome.
| int_19h wrote:
| I'm firmly in the static typing camp myself, but at the same
| time I think it's good that there's still a language that is
| unabashedly dynamically typed. Looking at Python, when you
| take a language that was originally designed around dynamic
| typing and then bolt static typing on top, the result is just
| awkward all around, and ends up being the worst of both
| worlds.
| berkes wrote:
| > "just write better code" to avoid these pitfalls
|
| A lot of issues in and with Rails code leans heavily on this
| idea. It often comes in other flavors like "You can write
| rails apps that perform really well" or "Its perfectly doable
| to write a clean easy maintainable codebase in rails".
|
| And is apparent in the "Provide sharp knives" doctrine as
| "And by capable, I mean knowledgeable enough to know when and
| how, accordingly to their context, they should use the
| different and sometimes dangerous tools in the drawers."
|
| I really dislike this approach. I don't want something that
| is full of foot-guns and therefore requires me to recognise
| them when I lack all information to do so.
|
| I've written terrible Rails apps, exactly because it allowed
| me to so, and I didn't know they would become terrible, until
| they were. I now recognise the (design) patterns that are
| foot-guns, I now know the tell-tales that show me where the
| sharp knives are dangerously placed. But then I get dropped
| into a Rails codebase that has seen 20+ developers coming and
| going over a decade, as the 21st developer, and I see it
| filled with these footguns and dangerously wielded "sharp
| knives". Often there's a lot of history apparent from these
| previous devs who saw this too and fixed some of it. But the
| overall state is still abysmal.
|
| Sure, it's all these devs that made it abysmal. But the
| ecosystem, the framework and the language allowed, and
| sometimes even encouraged them to make it that.
| Mystery-Machine wrote:
| The N+1 queries issue has been addressed in the latest
| ActiveRecord versions. If there's an N+1, you can set
| ActiveRecord to raise an error instead of making the N+1
| query. Bullet gem, for years now, has also been able to catch
| the N+1 queries and let you choose how you want to act upon
| that.
|
| It's true that monkey patching is a problem. I hear you. It's
| more and more problem of the past though. People realized
| it's too sharp of a knife and stopped doing that.
| nasmorn wrote:
| Rails has strict_loading now which eliminates the n+1 issue.
| Which kinda supports your position that tooling plays a large
| role. I was always very aware of the issue but framework
| support makes it 10x easier
| _joel wrote:
| Still a bunch of stuff that runs on ruby that isn't webdev,
| https://github.com/theforeman/foreman is a big one I can think
| of. Ruby's quite nice for sysadmin tasks, puppet, chef etc all
| in ruby iirc.
| JamesSwift wrote:
| Metasploit and homebrew also come to mind
|
| EDIT: also cocoapods
| cout wrote:
| I've built a lot of niche applications in Ruby, but a few
| years ago I switched most of my toy programs to python,
| because it's easier to find other devs who can meaningfully
| contribute if I write in python.
|
| At work I have been using Ruby for longer than rails has
| existed. In those days there were lots of neat uses for Ruby
| (one of the most interesting being at NASA), but none of us
| knew if it would ever catch on. We didn't care -- Ruby made
| programming _fun_, and we were happy to use it even if no one
| else ever did.
|
| It was partly the language that made Ruby fun but also the
| community. And it's out of this community that projects like
| chef, puppet, shoes, etc. were born. Matz has called Ruby
| human- oriented programming, and I can think of like that is
| human- oriented than community.
| lordofmoria wrote:
| Rails went through a down period 2014-2020 due to several
| reasons:
|
| 1. React burst on the scene in 2014
|
| 2. the hyperscale FANG companies were dominating the
| architecture meta with microservices, tooling etc, which worked
| for them at 500+ engineers, but made no sense for smaller
| companies.
|
| 3. there was a growing perception that "Rails doesn't scale" as
| selection bias kicked in - companies that successfully used
| rails to grow their companies, then were big enough to justify
| migrating off to microservices, or whatever.
|
| 4. Basecamp got caught up in the DEI battles and got a ton of
| bad press at the height of it.
|
| 5. Ruby was legitimately seen as slow.
|
| The big companies that stuck with Rails (GH, Shopify, Gitlab,
| etc, etc) did a ton of work to fix Ruby perf, and it shows.
| Shopify in particular deserves an enormous amount of credit for
| keeping Ruby and Rails going. Their continued existence proves
| that Rails does, in fact, scale.
|
| Also the meta - tech-architecture and otherwise - seems to be
| turning back to DHH's favor, make of that what you will.
| rgbrgb wrote:
| you might mean shopify, not spotify. I think spotify is
| python/go, whereas shopify was started by a rails core
| contributor and probably has the biggest rails deployment in
| the world
| dropofwill wrote:
| Spotify is mostly Java, with some Scala and Node.
| lordofmoria wrote:
| Yes, edited!
| hello_moto wrote:
| >which worked for them at 500+ engineers, but made no sense
| for smaller companies
|
| The number of hi-tech companies that grew from 37signals size
| to Uber size have also increased due to various reasons: SaaS
| becoming more and more accepted, WallStreet loves SaaS, and
| in general just more investment money in the market.
| hocuspocus wrote:
| The RoR hype started to wane long before React. You're really
| missing a huge part of our industry:
|
| - While most 2nd or 3rd tier tech companies don't need Google
| scale infrastructure, SOA in Java/C# and then Go is
| incredibly prevalent. Many teams never had a reason to even
| look at RoR and its considerably worse language and runtime.
|
| - Good ideas from RoR were copied by pretty much every
| ecosystem; again, most people never wanted Ruby in the first
| place.
|
| - Plenty of small web shops simply stuck to PHP.
| jonathaneunice wrote:
| It's stable and mature.
|
| Maybe you don't hear the constant clickity-clack of endless
| change as a result. Also true that Ruby's most popular in
| writing web apps and services, where it and Rails continue to
| shine.
|
| webdev FWIW is a ginormous part of this little internet thing.
| You know, those Web-based applications and services that run
| the entire global economy and human society, such as it is.
| hello_moto wrote:
| People never fully adopted Ruby for Ruby sake.
|
| People adopted Ruby because of Rails.
|
| Another more adopted Ruby software are probably fluentD and
| maybe Jekyll. The rest kind of comes and goes.
|
| Majority sys-admin toolings have always been dominated by
| Python and with k8s hype, some of the toolings have been geared
| towards k8s automation written in Golang.
|
| In general, sys-admin toolings are a mixed bunch: perl, shell,
| python, ruby
| dyingkneepad wrote:
| Speaking from my own experience at work, for non-webdev, if the
| project is something I'll want to share with other people,
| there is a great incentive in just using Python. I can't seem
| to get people to be interested at all in my tools if they're in
| Ruby. When I write stuff in Python, people naturally read, use
| and contribute.
| cout wrote:
| How would you define "hype"?
| cdiamand wrote:
| Anybody have any opinions on moving away from Redis for
| cables/caching/jobs?
|
| I supposed it'd be nice to have one less thing to manage, but I'm
| wondering if there are any obvious gotchas to moving these
| features over to sqlite and postgresql.
| nomilk wrote:
| I'm sticking with redis purely because it's battle tested and
| I'm not endowed with enough talent nor time to work through
| kinks in Solid.
| WillPostForFood wrote:
| Totally makes sense not to jump in early to make sure kinks
| are worked out, but it is worth noting that Solid Cache was
| code extracted from BaseCamp and HEY, so it has seen
| production at scale for a while now.
|
| https://www.youtube.com/watch?v=wYeVne3aRow
| lordofmoria wrote:
| I had a bad experience with Action Cable + Redis (extremely
| high memory overhead, tons of dead redis connections), so it's
| a bit "fool me once" with regard to action cables.
|
| The main argument for caching in the DB (the slight increase in
| latency going from in-memory->DB-in-memroy is more than
| countered by the DB's cheapness of cache space allowing you to
| have tons more cache) is one of those brilliant ideas that I
| would like to try at some point.
|
| Solid job - i just am 100% happy with Sidekiq at this point, I
| don't understand why I'd switch and introduce potential
| instability/issues.
| et-al wrote:
| What are you using in lieu of Action Cable for websocket
| connections?
| justinko wrote:
| Check out anycable
| xutopia wrote:
| For caching specifically solid_cache works better for long
| lived and larger caches than does Redis. If you need short
| lived and smaller caches Redis will be more performant for you.
|
| That said you can probably get away with caching way more with
| solid_cache and it's highly dependent on what your use cases
| are.
|
| Also a thing to note that your DB backing solid_cache might
| also be using RAM efficiently, giving you a lot of benefits
| that Redis did.
|
| For new projects I'll be using solid_cache first and adding
| Redis only on an as-need basis. The cost of Redis is orders of
| magnitude higher than a DB backed cache.
| cdiamand wrote:
| Thanks for this. I've run into "giant cache" issues in the
| past in this exact use case. I'll give solid_cache a look.
| ksec wrote:
| DHH mentioned 10 _TB_ of cache and only 0.5ms increase in
| latency difference between Redis and SQLite. I wish other
| could test it out and have some other figures to point to.
| But if the stated case were true then I think sacrifice
| 0.5ms for 10 to 20x more cached resources sounds like a
| very good deal to me.
| azuanrb wrote:
| On Rails homepage, it says from "Hello World" to IPO. The idea
| is that Rails should help you maintain a lean stack by default.
| You can stick with Postgres for pretty much everything:
| caching, background jobs, search, WebSockets, you name it.
|
| But, as your app grows, you can swap things out. Redis or
| Elasticsearch are solid choices if you need them. DHH mentioned
| that as well, at scale, everyone does things differently
| anyway. But you do have the option to keep it simple, by
| default.
|
| For me personally, Rails 8 is great. My new project only need
| Postgres and that's it. I don't need Redis, multiple gems for
| background jobs or cache anymore. Able to avoid the chaotic JS
| ecosystem for frontend. Hopefully it will be easy to setup
| Hotwire Native too. It really streamlined things, and letting
| me focus on building features instead.
|
| That said, for my production apps in existing companies, I'm
| sticking with what's already working: Sidekiq, Redis,
| Elasticsearch. If it ain't broke, why fix it? Will probably
| revisit this decision again in the future. Too early to tell
| for now.
| Lukas_Skywalker wrote:
| Regarding Hotwire Native: I tried Strada a few months ago,
| but I never got it to work. Hotwire Native was running within
| 10 minutes on each platform. The docs are miles ahead of the
| Strada docs imo.
| JamesSwift wrote:
| I havent used them, and we are not moving to them on our
| existing app but I can super-appreciate the fact that by
| default redis is more of a down-the-road decision now. No
| reason to get into the complexity (+ additional hosting cost)
| of adding another service into the mix until you choose to
| later on.
| nicoburns wrote:
| I've had good experiences using postgres for background jobs.
| olcarl wrote:
| I have used both with rails. (Cable is still going through
| Redis tho).
|
| Solid cache is perfect for my use case since page caches
| doesn't change as often, so taking a smaller memory footprint
| on the server farm is a win.
|
| My take is to measure your cache hit percentage. This will
| allow anyone to understand their cache eviction rates. If you
| have high eviction rates maybe using a btree is not the way to
| go and redis is probably better
| temporallobe wrote:
| I work on different projects that use with Rails and others that
| use a microservice-based architecture, and while the trend has
| been to encourage avoiding monolithic architectures like Rails, I
| can say that I highly appreciate what it provides at its core. I
| love that the Rails team continues to trudge forward to add value
| and improvements despite the trends.
| HatchedLake721 wrote:
| > the trend has been to encourage avoiding monolithic
| architectures like Rails
|
| I'd say's it's completely the opposite.
|
| Yes, microservices might've been the trend in late 2010s, but
| after everyone got burned by it with unnecessary complexity
| (unless you're at "Google" scale), people just went back by
| being productive building modular "monolithic" architectures,
| and using "microservices" only when absolutely necessary.
| zeendo wrote:
| Surely one can imagine a middle ground between one giant
| monolith and a huge mess of microservices?
| loloquwowndueo wrote:
| A distributed monolith! Worst of both worlds! I'm just
| kidding of course.
| moritonal wrote:
| Depends what you wanted from Microservices. If all you
| wanted was scale, then Rails ActiveJob solves that very
| effectively allowing you to scale your job-runners.
|
| If you're looking for the "mindset" of microservices, where
| you store the data separately and impotently, then I
| believe Rails discourages that mindset.
| berkes wrote:
| I keep hearing this "microservices to allow scale", in
| which "scale" implies performance, as some
| counterargument against microservices.
|
| Honest question, who ever _seriously_ proposed
| microservices to improve performance? It doesn 't take a
| lot of thought to figure out that microservices have
| overhead that will always put it in a disadvantage over a
| monolith in this regard.
|
| The only "scale" that makes sense wrt microservices is
| that of the scale of teams, and manage-ability of the
| scale of features and codebase. They are primarily a
| solution to "too many people working in too many poorly
| bounded domains". But as a solution to performance
| problems? Is it really proposed as that?
| spyckie2 wrote:
| It was proposed in the sense that Ruby, or python, or
| whatever webserver language you used (Perl, php, even
| JavaScript) was slow, single core, synchronous, database
| blocked, or whatever else made it "unscalable" and you
| built this tiny service that only focuses on your core
| bottlenecks like an api call that only returns
| coordinates of your map position on things like aws
| lambda.
|
| Then for some reason some junior engineers thought that
| you could make everything an api call and you can make
| services in the most optimal language and glue them all
| together to have functional "scalable" apps.
|
| And thus the horrors of being a web dev in 2016+ began.
|
| Of course it didn't help SPAs were encouraging backends
| to be decoupled from front ends and completely hidden in
| their implementation so the fact that "it was now
| possible" enticed backend devs to experiment with
| multiple api services.
| berkes wrote:
| Well, Ruby (on Rails) _is_ slow, single core,
| synchronous, database blocked and hard to scale. But
| certainly almost everyone realises that 's not a feature
| of it being a monolith, but comes from it's
| language/stack/paradigms (AR, template, dynamic, JIT
| etc)?
|
| I have, certainly, replaced some endpoints in Rails apps
| with lambda's, rust, or even standalone sinatra services
| for performance reasons.
|
| For example an endpoint that generated "default stable
| avatar pngs" for new users: Ruby just isn't cut for image
| generation and manipulation. Rewriting that in a stack
| that performed x100 in this use-case (we picked rust)
| took a lot of heat off the cluster of servers.
|
| Or moving the oauth and registration to a separate rails
| app that served these pages - the only endpoints that did
| HTML. Allowing the "main" Rails app to remain leaner by
| not loading all of the templating, and other HTML
| middleware in memory when it would never be used.
|
| In that sense, I guess, monolyths can have a performance
| disadvantage: they require the entire app to load stuff
| for that one endpoint or feature even if 99% of the
| requests and users never use that.
|
| Like the "PDF generation for reports" we once had, that
| was rarely used but still loaded in every running thread
| that would never handle anything related to reports or
| PDFs. Extracting that to a separate "PDF report
| generation worker" freed GBs of memory on almost all
| servers.
| nasmorn wrote:
| Image manipulation is the one thing I also run as a micro
| service whenever needed. I just set up imagor once and
| never need to manage that in the installation/images of
| all other apps. No extra memory for shelling out to
| libvips or imagemagick needed.
|
| The PDF use case also sounds very promising low hanging
| fruit
| singron wrote:
| This was seriously proposed by some. E.g. "scaling
| services independently"
|
| Scaling services independently is usually a recipe for
| outages where something is at the wrong scale. Sometimes
| you want to separate workloads that don't fit the request
| response model well because they take too long or use too
| much CPU or RAM, but you don't need micro services to get
| that benefit.
|
| I don't think anyone was claiming it would lower latency
| for typical requests except maybe indirectly through
| materializing views in event-driven architecture.
|
| I think the steel man has been about scaling teams, but
| the discourse was not limited to that.
| closeparen wrote:
| The idea of reserving some capacity for specific
| workloads make sense, but that's mostly a load balancer /
| job scheduler configuration thing. The latent capability
| to serve other workloads physically hanging out in the
| same binary is really unlikely to have a material impact,
| if you're not sending it any work.
| noworriesnate wrote:
| A modular monolith is distinct from a "plain" monolith.
| It's a good middle ground for most web services.
| crabmusket wrote:
| What's a "plain" monolith? Is a modular monolith "just a
| monolith except we don't suck at coding"?
| noworriesnate wrote:
| A modular monolith has a single executable which runs in
| different modes, typically depending on environment
| variables. So you can run three processes in the mode
| that handles web requests, five processes in the mode
| that processes events on a queue (e.g. Kafka), etc. Eight
| processes, running in two different modes, but it's all
| the same executable. That's the basic idea of a modular
| monolith.
|
| By "plain monolith" I meant just any kind of monolith.
| closeparen wrote:
| Let's use MVC for the sake of argument. A regular
| monolith has lots of models, lots of controllers, and
| lots of views. A modular monolith has several collections
| of models/controllers/views, which might be tightly
| coupled internally, but the collections as a whole
| exposes much smaller APIs to each other. You cannot just
| reach into an implementation detail of distantly related
| functionality, even if this functionality is "public" in
| the programming language package visibility sense (i.e.
| users repository is visible to users controller).
|
| This is basically what's accomplished by publishing a
| Thrift/Proto/OpenAPI IDL from a collection of packages
| comprising a network service. The key insight is that the
| serialization and networking parts of this are
| superfluous, what you actually wanted was the visibility
| rules.
| matt_s wrote:
| In some ways its more about organization of humans doing
| the work. Breaking some piece of a monolith off into its
| own application, not micro-service, has advantages that you
| avoid having to deal more than a 2 pizza team size on an
| app. Sometimes the business grows and you go from startup
| idea one-app-does-everything implementations into needing
| more de-coupled, single business responsibility
| organizations of code.
|
| I suppose places like Spotify or Github may have good
| practices around working on large monoliths but I would
| think that takes a lot of effort to get right and may have
| trade-offs.
| brightball wrote:
| This is correct.
|
| It was always more of a team organization solution than a
| system architectural solution. Leaning into it too much
| on the latter created a lot of complications for the
| former.
| imhoguy wrote:
| Modulith - you still program app usually as single repo
| project, but you take care about code level modularization
| so in any case you are able to simply extract separate
| (micro)service.
| karmajunkie wrote:
| yes, it's called SOA and it's been around for decades at
| this point.
| noop_joe wrote:
| Totally, I think there's a lot of retroactive justification
| for what's familiar whether it be microservice or monolith.
| They both have advantages and disadvantages -- we're at a
| point where deploying and running either is available on
| most clouds.
|
| That said, I think interesting possibilities exist where
| the two approaches are blended. I work for a cloud [1] that
| supports a concept of "services" grouped within an app each
| of those services is a web server that can be configured to
| sleep [2] under specific conditions -- effectively
| serverless but without the loss of shared memory and all
| the efficiencies of running a more traditional web server.
|
| The grouping of services also provides a way to spin off
| parts of an application while keeping it within the same
| deployment process.
|
| 1. https://noop.dev
|
| 2. https://noop.dev/docs/sleepy-services/
| hello_moto wrote:
| > people just went back by being productive building modular
| "monolithic" architectures, and using "microservices" only
| when absolutely necessary.
|
| The number of hi-tech companies that are in the middle-to-
| large scale have increased significantly from the first wave
| of Rails era.
|
| Majority of hi-tech companies with listed stock have
| complexity more than "monolithic" architecture.
|
| Sadly, if a company doesn't grow, they will get eaten by
| their competitors.
| int_19h wrote:
| > Majority of hi-tech companies with listed stock
|
| Isn't that kinda circular? Generally speaking, companies
| only list their stock when they grow large. The vast
| majority of web dev is not happening in those kinds of
| companies.
| hello_moto wrote:
| There are publicly listed hi-tech companies that may not
| be that big...
| sosodev wrote:
| You're generalizing way too much. There are still tons of
| teams out there running and creating new microservices.
| arunix wrote:
| Is this correct? Practically every job advert I've seen
| claims they are using microservices (and want candidates with
| such experience).
| Alupis wrote:
| It is not correct. This is the sentiment people who don't
| understand k8s often have, because of handwavy complexity
| blah blah blah. The predictable quote is always along the
| lines of "unless you're Google scale..." - which misses
| perhaps 80% of what microservices bring to the table.
|
| Then they go off and build complicated monorepos that take
| 6 months to learn before you can effectively contribute.
|
| All paradigms have trade offs. Engineering is about
| understanding those trade offs and using them where
| appropriate. Unfortunately too many people just jump on the
| "k8s is complicated" bandwagon (because it challenges most
| of the assumptions they've previously held in software
| development) and entirely write-off microservices without
| taking the time to learn what problems microservices solve.
| ninininino wrote:
| We stopped making microscopic microservices but we still ship
| services. Services are deployable independently from each
| other, can be scaled independently from each other. A
| monolith that results in a single build artifact / executable
| or whose contents must all run in a single pod or application
| server is inherently harder for larger teams to work on.
| Deploying a small change means re-deploying your entire
| application. Scaling your authz system means scaling up your
| analytics data producers. Separating your code into services
| that run and deploy independently from each other means
| organizations can scale without creating headaches for
| developers.
| ch4s3 wrote:
| > while the trend has been to encourage avoiding monolithic
| architectures like Rails
|
| I'm of the opinion that this was always bad advice for most
| people most of the time. Achieving any real infrastructure cost
| savings this was is difficult, its easy for delivery speeds to
| suffer, and the debugging experience is terrible.
| sergiotapia wrote:
| microservices, like graphql, have certainly fallen from grace
| by more senior engineers. i see mostly jrs advocate for it
| because that's what they were taught.
|
| a senior engineer will try to keep the monolith for only as
| possible and only then explore a new tiny service.
| Alupis wrote:
| To the contrary, it is often the "senior" engineers that
| refuse to learn new architectures, and only want to build in
| ways they already know and used in the past.
| solanav wrote:
| Is it me or is the introduction written in a very chatgpt-esque
| style?
| Terretta wrote:
| It didn't invent this corp-chipper style. It just read all of
| it.
| Kerrick wrote:
| Ruby and Rails really seem to be going through a renaissance
| lately.
|
| - The pickaxe book, Programming Ruby, has a new edition this year
| covering Ruby 3.3
|
| - The Rails Way is being updated for Rails 8 and is available in
| pre-release, and will have two companion books
|
| - A new title, Rails Scales, is being published by PragProg and
| is available in pre-release now
|
| - YJIT has made Ruby fast. Like, _FAST_
|
| - Rails has a bunch of new features that cover the "missing
| middle" levels of success
|
| - Ruby has a bunch of new and new-ish features like Data
| (immutable Struct), pattern matching, Fibers and Ractors, and
| more.
|
| I had largely moved on from ruby into the world of front-end
| applications by 2013, but now I'm excited about the prospects of
| diving back in.
| game_the0ry wrote:
| I would argue - its not a comeback, it was always the "king" of
| web dev.
|
| Seriously, other projects can use its success as a reference
| for implementation.
|
| And I say this as a front end dev.
| brandall10 wrote:
| As a Rails dev from 2011-2018, having returned over the past
| year, it def seemed there was an exodus in or around 2015.
|
| Part of it was due to the rise of SPA and Rails difficulty
| working with those (webpacker, anyone?), part due to poor
| perception of Rails 4, part due to newer options such as
| Elixir/Phoenix or Golang rising in popularity for backend
| work, part due to many of the leaders such as Yehuda Katz
| moving on.
|
| Also watching from afar on HN, it seems like Rails 7 release
| was perceived as a sort of comeback, with quite a few
| articles posted in recent years praising the framework for a
| return to relevance.
| nicoburns wrote:
| > part due to newer options such as Elixir/Phoenix or
| Golang rising in popularity for backend work
|
| I suspect Django and Laravel have taken a chunk of the
| market as like for like replacements.
| princevegeta89 wrote:
| Tried GoLang and also used Phoenix for a massive project
| which went well. But we had problems onboarding new folks
| into it and some junior and even senior engineers went
| bonkers trying to get their heads around FP and the elixir
| language in general. I would say it worked great for me,
| but the problems and the curve of learning for others in my
| team made it feel like Elixir creates that gap for teams in
| general.
|
| Go is good, but again I only tried it long ago and can't
| comment it for what it is today. I loved Ruby but I find it
| hard to go back to it after my experience with Elixir and
| Typescript. I was hoping for Crystal to go to great lengths
| but it doesn't seem to be the case at all.
| ch4s3 wrote:
| You do need to set some rule when onboarding people into
| an Elixir application. Not everything needs to be a
| GenServer, and please don't endlessly nest Enum.map
| calls.
| silenced_trope wrote:
| I also noticed an elitism from other devs when it comes to
| Rails devs. I literally heard on multiple occasions "we
| don't hire Rails devs here!" followed by a laugh.
|
| Of course it was tongue in cheek, if the candidate is
| amazing yes they're a hire.
|
| But it spoke to a reputation that Rails devs had seemingly
| received. I think because prior to JS/Node, it was Rails
| that offered newbies the fastest path into web dev.
|
| I don't believe this is the reason for any sort of exodus,
| but the negative perception may be partly a reason for devs
| choosing other frameworks.
| mdaniel wrote:
| > - YJIT has made Ruby fast. Like, _FAST_
|
| Then I pray with all my heart that GitLab moves to it, because
| that's one of the major complaints I hear about folks who use
| their web interface. Even while I was visiting the site to look
| up whether their main repo had a .devcontainer folder in it, I
| could just watch all the stupid ajax-y shit spin endlessly in
| what is conceptually a static table (sure, it changes per
| commit, but they're not a stock ticker platform)
|
| OT1H, I know, I know, "MRs welcome" but OTOH as a ruby outsider
| getting the dev environment up for contributing to them has
| been a lifelong struggle. Now that Rubymine has support for
| .devcontainer maybe it'll work better
| mattmcknight wrote:
| Well, a lot of those pages have Vue application running on
| them.
| jwcooper wrote:
| I'm not saying GitLab is poorly designed, but a poorly
| designed website will be slow on the fastest of languages or
| frameworks. It's not necessarily a Rails or Ruby problem
| here.
| ksec wrote:
| >Then I pray with all my heart that GitLab moves to it,
|
| YJIT does make Ruby fast, but that doesn't mean it makes
| _Rails_ fast. (yet) At least dont expect multiple times
| improvements.
|
| Hopefully in the future.
| byroot wrote:
| There's plenty of reports of YJIT lowering real world Rails
| applications latency by 15-30%.
|
| There is also plenty of perfectly snappy Rails applications
| out there. People need to stop blaming the framework...
| paulddraper wrote:
| GitHub has always been fast for me.
| klaussilveira wrote:
| Do you have any benchmarks to share on YJIT?
| pilaf wrote:
| https://speed.yjit.org/
| klaussilveira wrote:
| Also: Endless Ruby!
|
| https://bugs.ruby-lang.org/issues/16746
| bradgessler wrote:
| I'm optimistic about Ruby's async story with the work Samuel
| Williams has been doing. https://github.com/socketry/falcon is
| the tip of the iceberg, which is built on top of
| https://github.com/socketry/protocol-http2 and a not of other
| repos at https://github.com/socketry.
|
| It's inspiring other's in the community to think of interesting
| applications, like using the HTML slot API to stream responses
| to HTML without JS.
| https://x.com/joeldrapper/status/1841984952407110037
|
| I know other frameworks have had asynchronous IO support
| forever, but it's finally coming to Ruby that seems like it
| will stick around and be well supported.
| ksec wrote:
| My only concern is that none of his work is being picked up
| by Rails. As a matter of fact, it isn't just SW's work, the
| whole async story on ruby, it seems neither Fiber or Ractor
| has reached any mass adoption.
| frostymarvelous wrote:
| That's not completely accurate. Rails 7.2 added fiber
| support.
|
| Only action cable still doesn't fully support falcon using
| http 2. But that's coming soon as well.
| brightball wrote:
| My assumption is that's due to the use case benefits for
| it.
|
| More concurrency is not always ideal, especially if you're
| not in an environment that guarantees you won't have
| negative impacts or runaways process (BEAM languages, etc).
|
| Rails projects are typically so hardwired to use a
| background queue like Sidekiq that it becomes very natural
| to delegate most use cases to the queue.
| bradgessler wrote:
| There's various PRs where Fiber adapters are making their
| way into the Rails stack. Rails 8 added a ton of support
| for Fibers, with the exception of ActionCable. There's a PR
| open for that, which I assume will land sometime soon.
|
| Rails has been really slow to pick-up async/http-2. They
| don't know it yet, but Falcon and all async libraries
| Samuel is working on will probably be a huge them 1-2 years
| out when more people find out it means less infra has to be
| deployed to production environments. Right now folks are
| happy to deploy without Redis(tm) with the Solid stack, but
| a lot of that won't be needed if proper async support is
| baked into Rails.
|
| There's been a lot of Fiber features being committed into
| the Ruby language that I barely understand, but have
| improved all of these async libraries over the past few
| years. That's finally starting to bear some fruit for
| people like myself who don't really understand all of those
| details, but understand the benefits.
|
| It will happen, but these things tend to play out more
| slowly in Ruby, which is a feature or a bug depending on
| how you look at it.
| byroot wrote:
| > They don't know it yet,
|
| This is so condescending... We perfectly know about the
| pros and cons of the fiber scheduler.
|
| It's a very useful stack, but people, and you in
| particular, really need to stop selling it like it's the
| best thing since sliced bread. Async isn't a good fit for
| everything, and it's certainly not a good fit for the
| overwhelming majority of Rails applications.
| bradgessler wrote:
| I've heard from lots of folks in the Rails community that
| getting http/2 and streaming into Rails has been a slow
| and tedious process. I'm not saying it's going to be "a
| good fit for everything"--what I am saying is that it
| will be nice when we can run IO bound workloads in Rails
| without feeling like a fish out of water.
|
| "it's certainly not a good fit for the overwhelming
| majority of Rails applications".
|
| In my experience, most web applications are terminating
| HTTP connections from clients, then reaching out over a
| network to database servers, etc. to do work. This is
| very much IO-bound, so I'm not sure how this wouldn't be
| a good fit for most Rails applications.
| byroot wrote:
| > getting http/2 and streaming into Rails has been a slow
| and tedious process
|
| Bringing http/2 all the way to the Rails process doesn't
| bring anything to the table. You're much better to
| terminate http2 or 3 with SSL at the LB.
|
| > terminating HTTP connections from clients, then
| reaching out over a network to database servers, etc. to
| do work. This is very much IO-bound
|
| It absolutely isn't unless your data access is really
| messed up (badly indexed queries or tons of N+1).
|
| Even if you are just serializing the data you got from
| the DB down into JSON with little to no transformation,
| you'll likely end up spending more than 50% doing CPU
| work.
|
| Look at all the reports of YJIT speeding up Rails
| applications by 15 to 30%. If Rails apps were truly IO
| bound like people claim, YJIT would have nothing to
| speedup.
|
| Even if your app is 90% IO, you can slap Puma with 10
| thread and will already suffer from contention. Async
| make sense when you'd need more than a dozen threads or
| so does. Before that it doesn't make a substantial
| difference. Like it would be great to use for Action
| Cable, but that's it.
| chris12321 wrote:
| > In my experience, most web applications are terminating
| HTTP connections from clients, then reaching out over a
| network to database servers, etc. to do work. This is
| very much IO-bound, so I'm not sure how this wouldn't be
| a good fit for most Rails applications.
|
| Most rails applications are deployed using a multi-
| threaded application server such as Puma, a thread
| processes a single request and when it encounters IO (or
| calls out to a C function) the thread gives up its hold
| of the GVL and another thread can run. You can use 100%
| of your resources this way without the added complexity
| of parallelism within a single request.
| byroot wrote:
| So first it's a bit annoying to read this when I busted my
| ass for several weeks to refactor Active Record to make it
| more compatible with the Fiber use case in 7.2.
|
| But also there is very little benefit to it for the vast
| majority of Rails applications out there.
|
| Unless you are doing micro-services or something like that,
| your typical Rails application isn't IO heavy enough to run
| more than 2 perhaps 3 threads before contending.
|
| So the overwhelming majority of Rails applications wouldn't
| see any benefit from being served via falcon, quite the
| opposite.
|
| Async is great to enable some use cases where people would
| have to reach to Node before, but Rails will never be a
| good solution for that, if you want to do some sort of
| light proxy or websocket notification thing, Rails isn't a
| good solution, you want something much lighter.
| tinco wrote:
| Wouldn't fibers work well for ActionCable applications?
| Lots of connections being kept alive, with sparse
| activity on them?
| byroot wrote:
| Yes. But just for the Action Cable parts, as in you'd
| deploy Action Cable standalone with falcon, and then keep
| Puma or whatever for the purely transactional requests.
|
| If you don't, you'll notice that your Action Cable
| latency will be all over the place when a transaction
| request comes in.
|
| It's acceptable for "hobby" use, but if you try to
| provide a good user experience with reasonable latency,
| you can't just collocate Action Cable and the rest of
| Rails in a single process.
| agumonkey wrote:
| Interesting that both ruby and python are on the jit path. less
| is more.
| btown wrote:
| I think there's a new and healthy rivalry between Ruby, Python,
| and JS for web backends!
|
| - Ruby and Rails now has all of the things mentioned above and
| more. I do have concerns that Rails will evolve in directions
| where bundled frontends have less _official_ support, with the
| continued centralization of 37signals /DHH [0] and their
| controversial removal of Typescript from Turbo [1] (and
| bundling in general for Hey), but it's such a large community
| that there will be continued momentum in all directions.
|
| - Python used to be _the_ choice if you expected to do both
| data processing /machine learning/NLP and web backends in a
| centralized codebase with a single language. And Django is
| still a world-class solution there, with gevent + asyncio +
| forthcoming developments on GIL-less Python all contributing
| towards making Django a highly performant and parallel
| framework. That said, with much of an app's data processing
| complexity often best offloaded towards LLM-powered solutions
| that have dedicated APIs, and both Ruby [2] and Node having
| bindings to https://pola.rs/ as an alternative to Pandas, it's
| no longer the only solution.
|
| - And on the JS end, frameworks that enable full-stack
| batteries-included admin-out-of-the-box development like
| https://redwoodjs.com/ and https://www.prisma.io/nextjs + e.g.
| https://next-admin.js.org/ continue to evolve. Nowadays, if
| you're building a complex web application from scratch, Prisma
| provides all the escape hatches you'd need, so that you can
| build entirely in JS/TS and have the facilities you'd expect
| from Rails or Django.
|
| I'm really excited that all three communities are continuing to
| push the boundaries of what's possible; it's amazing to see.
|
| [0] https://news.ycombinator.com/item?id=30600746 [1]
| https://news.ycombinator.com/item?id=37405565 [2]
| https://github.com/ankane/ruby-polars
| acchow wrote:
| > - YJIT has made Ruby fast. Like, _FAST_
|
| Curious, I tried to look for some benchmarks, which still seems
| to show Node often being 3-10x faster
|
| https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
| HatchedLake721 wrote:
| I sometimes wish I had picked up Ruby/RoR instead of Node.js
| ~10-15 years ago.
| FigurativeVoid wrote:
| It's never too late! The Rails community is very welcoming.
| stouset wrote:
| No reason you can't start now!
| saltcod wrote:
| Curious if anyone is out there doing both effectively.
|
| Node at work, Rails on the side. Something like that. Feels
| like a lot to master, but not sure.
| moritonal wrote:
| Playing with a WebDev project in Node.js but jobs with Rails.
|
| Node makes things like OAuth trivial with the mix of Express
| and Passport, something that took me two weeks in Rails. But
| man does Rails make Sequelize look childish by comparison.
| FanaHOVA wrote:
| What's wrong with devise OAuth? Always found it super easy.
| Lukas_Skywalker wrote:
| I use Node at one of my employers, and Rails at the other.
|
| It is much easier to switch between them than I first
| expected. I can quite easily use the idiomatic patterns in
| either framework. But there are obviously very large
| differences in the two stacks. The most important that come
| to mind:
|
| - Rails is much more "batteries included". No need to decide
| what ORM, queue, mailer, remote storage, etc you want to use
| for the new project. You just use the built in solution. And
| you place the files in a pre-defined location. That makes it
| really easy to onboard new people, because they are familiar
| with the file structure. On the other hand, for Node
| projects, you can mix and match your components, and use
| simpler structures for side projects, and more complex
| structures (including tools like Nx) for more complicated
| projects.
|
| - The Rails ORM is much more powerful than the Node
| counterparts. I think it helps, that the ORM is built into
| Rails, so everyone contributes to the same product. For Node,
| it feels as if there are many ORMs that are 70% done, but
| don't cover important cases. One of them is fast but a bit
| buggy, one is slow but has the ability to deal with schema
| migrations, one is old and works well but does not support
| TypeScript.
|
| - Documentation of Node frameworks, for example NestJS, seems
| to be updated quicker than the Rails counterparts. For Rails,
| especially when Turbo was released, there was a kind of
| vacuum regarding the documentation. The docs for Turbo did
| explain the basics, but it was very very difficult to get it
| working with the official docs. Once blog posts started to
| pop up, it became much easier. Projects like Nest seem to
| have much more detailed documentation for their components.
|
| All in all, I do prefer Rails tbh. The DRY principle that the
| framework follows makes sure that you don't have to edit 8
| files when adding a new database column. This makes
| development much faster and in my opinion less error prone.
| wry_discontent wrote:
| I had a Rails job and slipped back into node, and it's so sad.
| Node is in a sad state compared to Rails. They don't even know
| what a framework looks like.
| tebbers wrote:
| It's the terrible standard library of JS that keeps me with
| Ruby. Rails makes it even better. Being able to write little
| things like 3.days.from_now to get a timestamp is great.
| chao- wrote:
| I agree that Ruby's standard libs are fantastic, but your
| example is from ActiveSupport, not the standard Ruby
| libraries. However, Ruby's well-thought-out object model is
| what makes libraries like ActiveSupport possible.
|
| I've used Ruby long enough to have some gripes about it,
| but I've worked in a half-dozen languages as well, and I
| have yet to meet an object model that I like better. That
| combined with the standard library, and the affordances for
| functional data pipelining, are what keeps Ruby among my
| favorites.
| ecshafer wrote:
| I missed the big Ruby on Rails fad because I was busy doing
| scientific computing at the time. But I picked up Rails 3 years
| ago for a job, and its fantastic. I do wish I picked it up 15
| years ago though, I would rather use Rails than Spring, akka,
| node, or any of the other frameworks ive been using.
| throwaway918299 wrote:
| If you do node professionally, you should be able to pick up
| Ruby on Rails in a weekend.
| blakedzc wrote:
| I recently went with Laravel, but I really wish I found Django,
| Laravel, or Rails instead of Angular and React when I was
| getting started. I'm not a professional dev, but the code I
| have done at work is all Node. Really happy to see that Rails 8
| shipped with an option for auth as well, when I did the Rails
| demo when evaluating it I was a bit shocked to find there
| wasn't a first-party solution for auth.
| hamandcheese wrote:
| I'm curious what the state of Sorbet + Rails is these days. I've
| been out of the ruby game for a little while now.
|
| Last I recall: sorbet itself is quite good once it is well
| established in a project, but adding type checking to a project
| (especially a Rails project) is a lot of work.
| jack_riminton wrote:
| Considering how anti-types dhh is, there is not going to be any
| official support for this anytime soon.
|
| In his most recent interviews the philosophy can be summarised
| as "if you love types, good for you, but rails isn't for you"
| block_dagger wrote:
| This is pretty close to Matz's stance as well.
| mahatofu wrote:
| Personally, the argument for strong types is when you're
| writing critical foreseeably permanent architecture. It's
| an extra layer of security and explanation.
| yoran wrote:
| We use it extensively in our codebase. We started without any
| types, and added Sorbet later. It's similar to Typescript as
| that you can gradually sparkle your code with types, building
| up the typing coverage over time.
|
| I just completed a big refactoring. We have a good suite of
| tests. But Sorbet has provided an added layer of confidence.
| Especially when it comes to the treatment of null values.
| Sorbet will raise an error if you try to call a method on an
| object that may be null. So it forces you to think through:
| what should happen if the object is null?
|
| So the tests combined with Sorbet typechecking made that we
| could just almost blindly deploy refactoring after refactoring,
| with only a handful of bugs for several 1000s of lines of code
| changed.
| gejose wrote:
| We use sorbet pretty extensively. Overall it's been a net
| positive, but if you're coming from something like typescript,
| IMO it's far, far behind in terms of usability.
|
| You can get pretty good value from things like intellisense in
| your editor, knowing that the constant you're referencing or
| method you're calling exists etc, but most libraries have no
| typings in sorbet-typed (beyond `T.untyped`).
|
| The last post on Sorbet's blog was from 2022
| https://sorbet.org/blog/, so I'm not sure how actively it's
| being developed. (compare that to typescript where you have a
| post every month https://devblogs.microsoft.com/typescript/)
| riffraff wrote:
| AFAIU sorbet is still being developed actively enough at
| Stripe, but I think there's also ongoing work at Shopify to
| integrate the Prism parser APIs which will be available in
| Ruby 3.4 this December
|
| https://github.com/sorbet/sorbet/network
| int_19h wrote:
| IMO the biggest problem with Ruby is still the docs. When you
| look at https://www.ruby-lang.org/en/documentation, you see a
| bunch of books - some of which are considerably out of date by
| now - and the official "API docs". For some mysterious reason,
| all the actual language features are also listed under API:
| https://docs.ruby-lang.org/en/3.3/syntax_rdoc.html. Worse yet,
| there's no proper table of contents - you get a kind of index on
| the left, but it's alphabetically sorted, and things on the same
| level are often unrelated. Compare to Python, where you have
| https://docs.python.org/3/reference/index.html that one can just
| read in order and end up with a very good understanding of the
| language.
| mooktakim wrote:
| those old books are still good though. There's only new syntax
| for latest ruby versions.
| int_19h wrote:
| If you compare, say, C++03 and C++14, it's also technically
| true that "there's only new syntax", but in practice this
| often means that hacks that used to be idiomatic before are
| frowned upon now.
| mooktakim wrote:
| Its not anything like that. new ruby version has "better"
| short hands, like {:test => 123} to {test: 123}.
|
| Anyway, there have been updated versions of the books and
| content online if people are interested.
| nextos wrote:
| Ruby has evolved slowly language-wise compared to C++, or
| even Python.
|
| Most changes have been in libraries and interpreter / VM
| implementation.
|
| Updating your knowledge from Ruby 1.8 (mid 2000s) to 3.x
| (current) takes little effort.
|
| But yes, sparse API documents were always a problem because
| a big chunk of the community was Japanese.
| uticus wrote:
| Ruby dev for several years, I agree with this. It's a
| frustrating point, especially after you learn the language and
| want to use the API docs as a reference. And I say that as a
| fan of the language.
| sprkwd wrote:
| It's heartening to see Ruby and the Rails community go from
| strength to strength. When I was a developer I loved the Ruby
| language.
| megaman821 wrote:
| I don't use Rails, but those Solid Adapters look cool. I think
| people would be surprised how long a RDBMS good enough before
| moving to more specialized solutions. Just jumping to best of
| class solutions for cache, pub/sub, full-text search, vector
| search, document storage, etc. adds too much operational
| complexity if you can get by just using a single database.
| ksec wrote:
| All the Solid Adapters but they couldn't name one as Solid
| Snake. Huge waste of opportunity. Hopefully more to come in 8.1
| sarlalian wrote:
| Solid Snake really should end up in the python world.
| 0xblinq wrote:
| Or an adult movie
| mikey_p wrote:
| Years ago I was working on a large Drupal site hosted on AWS
| with RDS MySQL and ElastiCache for caching. We noticed that
| ElastiCache was slower than we expected and switched the
| caching backend over to use the MySQL implementation in a
| simple KV table, and it was quite a bit faster than ElastiCache
| for most operations.
|
| People really underestimate how good modern RDBMS are,
| especially when they have their query cache tuned properly,
| there's no reason to be slower than Memcache or Redis.
| square_usual wrote:
| What's the difference between the new `script`
| directory/generator and using rake? I thought rake was meant for
| basically those things?
|
| Also, is there a good reason to use thruster instead of caddy?
| mplewis wrote:
| I really don't understand the NIH that the Rails team is
| bringing in with Kamal and Thruster. Not everything that HEY
| uses has to be pushed onto folks at other companies.
| Mystery-Machine wrote:
| Nothing is pushed. You can upgrade your Rails 7 application
| to Rails 8 today and no Solid* nor Kamal nor Thruster will be
| used in your app. It's there for you to use it. If you don't
| want to use it, don't. They released these new tools and, if
| you want to use something else, you can. That's the whole
| idea of Rails.
| mostlysimilar wrote:
| I recommend watching the Rails World opening keynote for some
| context: https://www.youtube.com/watch?v=-cEn_83zRFw
| bibstha wrote:
| This will answer your question:
| https://github.com/rails/rails/pull/52335#issuecomment-22395...
|
| > I think there can be some overlap between rake tasks and one-
| off scripts and opinions may vary. In the related discussion
| Okura Masafumi mentions that rake tasks are one way but they
| can be executed multiple times, and I tend to agree, leaving
| rake tasks for code that is intended to be run multiple times.
|
| > So script/ can hold one-off scripts, for example Basecamp
| uses script/migrate which I am guessing they use for updating
| data, and we had a similar folder at my previous company.
|
| > But script/ is not only for one-off scripts, it can hold more
| general scripts too, for example rails generate benchmark
| already generates benchmarks in script/benchmarks, and at my
| previous company we had script/ops which had a bunch of shell
| scripts and ruby scripts for various ops-related things.
|
| So really not so clear description. It caters to those who feel
| like they have a script that doesn't really fit in the Rake
| file.
| wkirby wrote:
| I still think, pound for pound, it's hard to beat the
| productivity and stability of rails as a framework for new web
| projects. Welcome changes here, but most notably, this new major
| version update doesn't appear to have any real breaking changes
| with the apps we've been running in production for years.
| dewey wrote:
| I'm mainly a Go developer but I've picked up Rails when version 7
| came out for all my hobby projects and it's just _fun_ to work
| with. I don't have to work with complicated frontend tooling and
| I just push to Dokku to deploy.
| ashconnor wrote:
| That new proxy they've developer "thruster" is written in go
|
| https://github.com/basecamp/thruster
| geoka9 wrote:
| As a backend Go developer who had used Rails a lot many years
| ago, I recently had to do a full-stack project where I got to
| pick my own stack. I liked the idea of HTMX and also added
| a-h/templ into the mix. I feel like this setup allows me to be
| almost as productive as with Rails when doing things that Rails
| is good at, while enjoying the control and simplicity of the Go
| approach.
| Sphax wrote:
| templ is great, it's been my go to when working on web stuff
| with Go.
| elfelf12 wrote:
| What do you use for frontend tooling then? Somehow you have to
| compile scss and do some mild js bundling or so?
| GreenWatermelon wrote:
| Rail embraced #NOBUILD starting Rails 7.
|
| No pipelines, no minification, no nonsense, just serving js
| and css directly.
|
| Hey.com works like this, and they reported nothing but
| improvement.
| resters wrote:
| Some really great ideas came out of Rails 1 and 2. After that
| Rails became more of a business, but good ideas still came out of
| the ecosystem and germinated (in my view more successfully) in
| the fertile soil of node / js, as well as sinatra -> flask /
| express, etc.
|
| But Rails' core value prop (doing a lot with strongly opinionated
| structure) is still useful to a lot of people.
|
| My complaint was always that version upgrades in rails were too
| costly -- teams would spend months -- and it wasn't usually clear
| whether upgrading was worthwhile. Also the business aspect led to
| a lot of ephemeral (very hot and then soon unmaintained)
| patterns/libraries.
|
| Rails 8 makes me want to look again and see how the system
| overall has matured.
| nomilk wrote:
| > led to a lot of ephemeral (very hot and then soon
| unmaintained) patterns/libraries
|
| For hard core web enthusiasts it makes sense to keep toward the
| cutting edge, but for boring old sites you just want have them
| run well and not have to worry about swapping out x for y every
| few months.
|
| I look forward to swapping out sprockets but I know there'll be
| teething issues. Same for built in authentication, so I won't
| be swapping out devise any time soon, probably ever. Same with
| redis for solid (won't be changing any time soon).
|
| Absolutely love the continued work on rails, but it doesn't
| mean I'll necessarily those new features, which is totally cool
| - rails doesn't force you to.
|
| With so much mix-and-match it can get confusing though. When I
| see a tutorial using importmaps I get confused because I only
| know esbuild. Now there's propshaft. Similarly with asset
| pipeline, I sometimes struggle with sprockets, now there's
| something new to learn and all its interactions with other
| pieces. (mostly paths and debugging is what I have trouble
| with, i'm no JS wizard [or ruby wizard for that matter]).
|
| (I just want to spend 95+% of my time making things that solve
| real problems, not tinkering with and finessing pieces of the
| framework)
| Lukas_Skywalker wrote:
| I have already upgraded to Rails 8 and am currently writing a
| guide on how to use Propshaft (because I was unable to find
| important infos). It's far from ready, but I plan to include
| a wizard that allows you to select your needs and it spits
| out the combination of jsbuild/cssbuild/importmaps/dartsass
| that you need.
|
| In short: if your application only needs distribution-ready
| JS and CSS (from libraries like Bootstrap, Splide or
| Lightbox2) you only need importmaps-rails. If you use SASS,
| you need dartsass-rails. And if you need to compile TS (with
| esbuild or webpack) you need jsbundling-rails.
|
| Especially the first case got a lot easier with Propshaft.
| xutopia wrote:
| Upgrading from 1-4 was difficult but since 4 it has been really
| easy. Often times nothing much to do from one version to the
| next.
| stuart_real wrote:
| As per GitHub's popularity chart, Ruby was the #5 language in
| 2014, and #10 in 2022 - https://octoverse.github.com/2022/top-
| programming-languages
|
| Starting a new commercial project/company in 2024 in Ruby is
| questionable.
| pjm331 wrote:
| one could also argue that making tech decisions based on
| popularity charts is questionable
| stuart_real wrote:
| One could argue that making tech decisions while completely
| ignoring popularity charts is more questionable.
| Mystery-Machine wrote:
| You're right. Those shouldn't be completely ignored. They
| probably shouldn't be the only argument to make tech
| decisions upon. Did you ever build any webapp in Ruby on
| Rails? You should check it out!
| pdntspa wrote:
| Rising from #10 to #5 seems to imply that a lot of people are
| making 'questionable' decisions. As an active senior RoR dev
| since like 2014ish seeing that makes my heart atwitter :)
| stuart_real wrote:
| I corrected the mistake. It went from #10 to #5. Only
| language with such secular decline.
| Mystery-Machine wrote:
| Pardon my sarcasm: You should work on WordPress. It's the
| most popular website framework in the world.
| hakunin wrote:
| Correction: you mean 2014, not 2024.
|
| Do you think there is no criteria worth considering besides the
| size of the hiring pool? What if 2 hiring pools are
| sufficiently big, do you still pick the bigger one every time?
| stuart_real wrote:
| Thanks. Corrected.
|
| > Do you think there is no criteria worth considering besides
| the size of the hiring pool? What if 2 hiring pool are
| sufficiently big, do you still pick the bigger one every
| time?
|
| It is not just a hiring pool. Look at various third-party
| SASS tools, they see Ruby as a second-grade language to
| support.
| hakunin wrote:
| That's not at all my experience. There's a one-line
| integration between almost everything under the sun and
| Rails (business/traffic analytics, performance/profilers,
| error notifications, logging, object storage integration, I
| could probably go on). Many other frameworks don't even
| have the general capability of doing one-line integrations.
| trevor-e wrote:
| I really want to try Rails, but the main selling points to me
| were the fast scaffolding and opinionated structure. With the
| advent of AI editors, are these points still relevant? Last I
| tried, CursorAI struggled with Ruby due to the lack of types. It
| seems like nowadays you can be nearly as productive with Node +
| Typescript + Cursor.
|
| edit: care to explain the downvotes for asking a question?
| bibstha wrote:
| Very much. I still heavily use rails generators as the defaults
| do quite a bit already. Generates nice forms, models,
| migrations, jobs, scripts, and test files. It doesn't feel
| much, like it's just generating a bunch of files with basic
| defaults in the right folder, but when you do that quite a bit
| overtime, you appreciate how little you have to think about
| those things.
| Mystery-Machine wrote:
| I hear you. I use Cursor editor. I work with all of these
| technologies: Ruby on Rails, React, Next.js, Django, vanilla
| JS, jQuery, HTML/CSS, Tailwind...depending on the project.
|
| I just spent the past week working on a hackathon where I built
| the project using a Node.js closed-source platform that uses
| Fastify edge functions and Cursor's autocomplete was terrible.
| Much worse than what I'm used to when Cursor makes
| autocompletion for Ruby/Rails code. JS libraries come and go
| every day. This makes it difficult for Cursor team to update
| their LLMs to provide good autocompletion. On the other hand,
| Ruby and Ruby on Rails have seen very few radical syntax
| changes. The syntax and majority of the API has remained the
| same.
|
| Ruby on Rails is so much more than just fast scaffolding. The
| code I've written a decade ago in Ruby on Rails, I can still
| pick it up today and understand the project. I can also pick up
| anyone else's project and figure out the intricacies of it much
| faster than I'd ever be able to do in say Next.js or Express
| project. Express feels like writing assembly (no hard
| feelings).
|
| I've, unfortunately, recently started working on a project
| that's written in Django. I thought Django is just Ruby on
| Rails for Python. Boy was I wrong... But that's a story for
| another time.
|
| IMO Ruby on Rails is an absolute king! However, I'm looking
| forward for a day when I'll be able to use one language on both
| frontend and backend, while having the same simplicity and
| functionality as Ruby on Rails. (I'm looking forward for Ruby
| on Rails JavaScript successor, but it's just not there yet.)
| textread wrote:
| Please do tell us the Django horror story
| trevor-e wrote:
| Nice, so Rails does work well with Cursor? I'll give it a try
| then. Like you said, maybe it just struggles on random Ruby
| code but not Rails which has a ton of existing examples to go
| off of.
| unethical_ban wrote:
| I asked Claude some questions about rails and I thought it was
| helping, but then I switched to working through the Blog
| example walkthrough on the rails website.
|
| Understanding the "why" and all the default conventions really
| makes you get what's going on.
|
| I guess my thought is, understanding an app is still important,
| and rails helps you understand easily.
| swombat wrote:
| I've been working with RoR since back in 2008 (Rails 2.1 yay!).
|
| I'm still working with RoR.
|
| It's _still_ an incredibly quick, powerful, flexible, versatile
| framework. I 'm able to build pretty large and complex apps all
| by myself, quite quickly, without fuss.
|
| I'm looking forward to the deployment improvements since that was
| one of the shortcomings that was still around. Kamal v1 didn't
| really do it for me (currently using Dokku instead). Maybe Kamal
| 2 is it.
| justinko wrote:
| 20 year Rails veteran here looking for a full-time position. My
| GitHub handle is the same.
| uhtred wrote:
| Hoping for a renaissance of frameworks like rails and django now
| that we have tools like htmx.
|
| Such a nicer way to build stuff.
| gejose wrote:
| I find that I have a love/hate relationship with Rails. Love the
| framework, not so much the language, particularly how it doesn't
| have static typing. Really easy to write, but hard to refactor in
| my opinion.
|
| I've been looking for a framework as good as rails for
| typescript, but haven't found anything to that level. The closest
| I've seen so far have been:
|
| * Adonis https://adonisjs.com * NestJS https://nestjs.com
|
| Is there anything better than these for the node world?
| mike_ivanov wrote:
| https://stackoverflow.com/questions/2690544/what-is-the-diff...
| gejose wrote:
| Thanks - updated to 'static' instead of 'strong'
| xcskier56 wrote:
| I've been a rails dev for over a decade... love the framework
| and the language. About a year ago we started a client project
| where they had a fractional CTO that wanted to do the API & UI
| in typescript and so we settled on Nest.JS... tl;dr Nest is
| about as good of and opinionated of a framework as I've seen in
| Node land, but it definitely has it's edges:
|
| - ORM: Like another commenter said, the ORM landscape in the
| node/typescript world is lacking. Every project feels like it's
| 70% complete and while you can find a project for each feature
| you want, you can't find one project with all of them. Ended up
| with TypeORM which has been very meh. - AuthZ: We went with
| casl which has a very similar feel to cancancan but lacks many
| of the important features for implementing more complex authz
| patterns like "you can edit this if you are in the group that
| owns this item" - Testing: Using Jest but the DSL and
| setup/teardown is way more complicated than rspec. -
| Flexibility. Patterns like single table inheritance and
| polymorphic relationships are poorly supported/fully lacking in
| typeorm and this bit us. - Learning curve: the DI system in
| Nest had a long learning curve, and having to sift through half
| a dozen or more options for each critical package (ORM, AuthN,
| AuthZ, etc) instead of having 1 or 2 clear choices made getting
| the project off the ground much much slower than anticipated.
| This can also just be chalked up to being green to the Node API
| landscape. - Adding to the learning curve, you have to be much
| more thoughtful about your code organization and architecture.
| We have an issue where we've introduced circular coupling
| through db-level repositories that is very hard to untangle.
| Rails gives you a great standard to work from that will take
| you a long ways
|
| All in all it wasn't a terrible experience but the complexity
| of the domain lead to some challenges that we could have
| probably solve more elegantly and quickly in Rails. Even after
| a year of working the in project, I'd say my velocity for
| medium/simple tasks is still only 80% of what it is in Rails.
| Definitely lower when more complicated features are involved
| itake wrote:
| Lots of great features for new rails apps, but what about the app
| was has been upgraded since rails 4?
|
| Are people actually going to spend time to replace redis or
| devise?
|
| I wish they'd add new features instead of trying to get people
| off successful 3rd party gems.
___________________________________________________________________
(page generated 2024-10-07 23:01 UTC)