[HN Gopher] Ruby on Rails Audit Complete
___________________________________________________________________
Ruby on Rails Audit Complete
Author : todsacerdoti
Score : 200 points
Date : 2025-06-12 08:15 UTC (4 days ago)
(HTM) web link (ostif.org)
(TXT) w3m dump (ostif.org)
| ksec wrote:
| May be even better to link it to the PDF? [1]. From the Changelog
| I am also guessing most of these are not fixed in 8.0.2? I wonder
| if they will come with Rails 8.1 which is still not released.
|
| [1] https://www.x41-dsec.de/static/reports/X41-Rails-Audit-
| Final...
| technion wrote:
| You really dont want strict same site cookies for the most
| part. I get that its "more secure" but as soon as someone
| clicks a link from somewhere else, you open it without being
| logged in.
| sgt wrote:
| Can they please do Django?
| immibis wrote:
| You can pay for one.
|
| Fast, cheap, good - pick two. Seems like a non-profit fund paid
| probably tens of thousands of dollars for this RoR audit. Can
| you raise the same amount to audit Django or convince a fund to
| spend money they already raised? If so, great!
| hhthrowaway1230 wrote:
| Thats good news! I'm a huge fan or Rails but a little surprised
| of such little vulnerabilities tbh. Would have expected more for
| such large codebase. But happy to hear it aint!
| maxdamantus wrote:
| I don't think it's meant to be a complete audit of the
| codebase, and in fact this is alluded to in the final report
| [0] (though the wording is strange--perhaps they forgot to
| update it from an earlier report):
|
| > Due to the size of Ruby on Rails, it will not be possible to
| cover all the tests and tasks in the following test plan. The
| tests performed will be covered in the final report along with
| suggestions on what to focus on in future audits.
|
| I feel like these sorts of audits are usually performed on
| individual applications rather than "mature" already widely
| used frameworks. I've got the sense that they are meant to give
| confidence that the developers knew what they were doing (since
| they focus on typical vulnerabilities that good developers
| should know about), rather than proving anything about the code
| base. Still better than nothing.
|
| [0] Section 3.7, https://ostif.org/wp-
| content/uploads/2025/06/X41-Rails-Audit...
| hhthrowaway1230 wrote:
| Thank you for clearing this up!
| yurishimo wrote:
| Wordpress is similar. The core project is quite battle tested,
| but the plugin ecosystem opens admins up to problems. With any
| system that allows modular code additions, the weakest attack
| area gets exponentially larger.
| mediumsmart wrote:
| I settled for the Rails Way using a subset of the defaults. _Not
| disappointed_
| runjake wrote:
| Elaborate on your experience?
| mediumsmart wrote:
| I am not a programmer and I am still working on my first
| rails project using AI and the guides. With that, my
| experience is mostly positive. I want it to be as simple as
| possible so not devise, no cable or actiontext or mail etc.
| (subset) - then I want sqlite for production since I will
| have max 8000 users - mostly read operations. Importmaps
| (takes time to get the AI to write js that passes
| jslint.com), plain css, deploy on apache proxy using systemd.
| What made me comment was that a while ago I was considering
| to use VIPS because I heard that its much faster and scales
| better. But since there was the default minimagick I stuck to
| that, so I was not disappointed when I read the audit.
|
| A seasoned rails developer would know how to do what I want
| but I only have the chatgpt which keeps trying to push me to
| use all these Gems so I can scale to my 2 Billion users when
| I go IPO...
|
| tl;dr working on my little rails site and learning is a joy.
| Levitating wrote:
| > Rails application server (e.g., Puma, Unicorn)
|
| I think it's more appropriate to call those Rack application
| servers, Rack being the Ruby CGI Rails implements.
|
| It's a minor nitpick.
| BilalBudhani wrote:
| I'm glad to see efforts towards improving Ruby on Rails security,
| it honestly keeps the framework still the most viable choice.
| ukprogrammer wrote:
| The productivity of Rails for B2B 'CRUD' software is unmatched.
| Surprised to not see more newer startups make use of it!
| nurettin wrote:
| The entire 2012 scene used Rails. Then they realized it was
| hard to scale and rewrote everything in Go.
| rco8786 wrote:
| > Then they realized it was hard to scale
|
| A rumor perpetuated by exactly one company - Twitter. I know
| because I was there when it happened and helped dismantle the
| original monolith.
|
| Rails scales just fine for 99%+ of business cases. If you're
| doing a sustained 5k writes per second with bursts up to
| 100k...sure maybe you need something more specialized.
| jerf wrote:
| Rails has been around for time to change the calculus on it
| too. It came out in 2004. The smallest instances you can
| get today on AWS would have counted as fairly powerful
| servers back then (with insanely fast CPUs), and by the
| second or third smallest you're beyond anything available
| at the time, and there's still room to run after that.
|
| Even the slowest web frameworks running on modern hardware
| take some quite substantial load before they're a problem.
| It's good when choosing a framework to consider if you're
| doing stuff where that might be a problem, but it's also
| good not to overestimate the performance needs for your
| site.
| vidarh wrote:
| Twitter also would've scaled a lot further on Rails just by
| dismantling the monolith. I don'tike Rails (though I love
| Ruby), but the way Rails was scapegoated for an original
| architecture that was not suited for scale irrespective of
| framework or language was annoying.
| rco8786 wrote:
| Yep totally agree. And also realistically once we hit
| that kind of scale it was perfectly reasonably to start
| looking at other options as well.
|
| It's been a while but I think we were at like 250mm MAUs
| when we finally decided to break up the rails monolith
| (and I think it was still on Rails 3 at the time, but
| don't quote me on that). The number of companies that
| ever hit that kind of scale approaches zero, and even
| less in the B2B space.
| kloop wrote:
| That makes perfect sense for people that need to scale. But
| doesn't explain why newer start ups aren't using it.
|
| Doing things that don't scale is a proven strategy at the
| beginning, pg even has a post about it
|
| https://www.paulgraham.com/ds.html
| dismalaf wrote:
| > But doesn't explain why newer start ups aren't using it.
|
| Plenty of newer startups use Rails. At least several pretty
| much every YC batch. You just need to pay attention.
| wiseowise wrote:
| No static typing would be a good dealbreaker for us.
| vinceguidry wrote:
| Ruby has static type system built into the language.
|
| https://github.com/ruby/rbs
|
| There are others you can use if you like.
| wiseowise wrote:
| Unusable mess.
|
| Ruby should take lessons from Python and TS on how to
| make proper gradual typing.
| Lio wrote:
| I think a much better way forward is proposed by Jake
| Zimmerman[1] of the Sorbet team. That is to allow the
| runtime to parse RBS inline format comments.
|
| That retains Sorbet's fast static checker and its runtime
| checks which Typescript compiled to JS lacks.
|
| 1. https://blog.jez.io/history-of-sorbet-syntax/
| burnt-resistor wrote:
| steep and rbs don't work so well and are the wrong
| approach. sorbet is also the wrong approach but it works
| better. The Python 2 -> 3 way would've been a better way
| to do it but Matz chose an unwise way (separate files)
| that doomed it combined with a failure to type all the
| things and make it work. Oh, and very few Ruby gems are
| cryptographically signed and so most code is mostly
| untrustworthy. Making important things optional makes
| them unused and essentially worthless.
| vinceguidry wrote:
| All of these problems are worse in javascript.
|
| > a failure to type all the things and make it work
|
| Everything is typed in Ruby.
| byroot wrote:
| Nah. If anything it's NodeJS that ate Rails' lunch. Around
| 2013/2014 it took over as the defacto default stack for
| startup.
| aqme28 wrote:
| It scales just fine. AirBnB, Github, and Shopify use it.
| nopcode wrote:
| It does now, but it took a few years for rails to do what
| nodejs did when it came out (the live chat demo app).
| mrinterweb wrote:
| The rails doesn't scale trope is pretty old at this point and
| has largely been discredited. Don't believe me, take a look
| at Shopify or Github.
| kybishop wrote:
| After programming with elixir and phoenix for a few years (with
| many prior years of rails experience) I have a hard time seeing
| why one would choose rails.
|
| Elixir is more performant, has compiler safety guarantees that
| are only getting better as types are introduced, is actually
| designed from the ground up for web dev (being based on the
| Erlang VM), and... it's just way more fun (subjective I know).
| Elixir is what I always wished Ruby was, and I couldn't be more
| excited about the coming type inference.
|
| Programming with Elixir makes me feel like Ruby is a previous
| generation language, much like Ruby made me feel that way about
| Cobol or Fortran, it really is that stark.
| Shank wrote:
| > I have a hard time seeing why one would choose rails
|
| I like Ruby, and I feel it has significantly prettier syntax,
| to me, than Elixir. So that's a big reason why I also like
| rails.
| throwawaymaths wrote:
| It's a matter of taste, but i found Ruby syntax to be
| annoyingly inconsistent, and do |..| ... end being
| something that isn't quite a lambda a huge source of
| confusion.
|
| also activerecord doing "trust me bro" things behind the
| scenes (like pluralization) drove me up the wall.
|
| to be fair ecto does a small bit of this too, but at least
| it doesn't change spellings (so you can global search an
| identifier).
| sanswork wrote:
| I switched fully to elixir close to a decade ago now and
| library availability is still lagging. For pretty much any
| company I can be pretty sure there will be
| JS/Ruby/Python/C#/Java integrations/libraries and
| occasionally you'll find one for elixir maintained by someone
| that stopped responding to github issues 3 years ago.
|
| It's definitely better but I can definitely see why you'd
| still choose rails these days.
| kybishop wrote:
| I agree with this sentiment, though in practice it doesn't
| seem to be much of an issue the vast majority of the time.
| Sometimes you do need that niche library though, and end up
| forking and updating for your needs.
|
| Given how rarely this comes up it feels like a tolerable
| problem that will only diminish as Elixir adoption
| continues to increase; I am aware of many rail shops that
| are slowly and quietly switching everything to Elixir, and
| it feels like that snowball continues to pick up pace as
| Elixir improves and those libraries are created.
| sanswork wrote:
| It may come up rarely for you but for my workflow I hit
| into it at least once a month and if you're a new user
| you will hit into it more frequently as they initially
| port stuff over. I'm not sure what the solution is and it
| obviously hasn't been enough to keep me out of the
| ecosystem but it is something that is noticeably worse.
| demosthanos wrote:
| > is actually designed from the ground up for web dev (being
| based on the Erlang VM)
|
| Nit: this makes it sounds like the BEAM was designed for web
| dev, which it was not. Erlang came out of Ericsson and was
| built for telecoms (OTP stands for Open Telecom Platform),
| which is where its unique set of trade-offs comes from. Many
| of those trade-offs make a ton of sense for web but that's
| not because it was designed for web, it's because there's
| overlap between the fields.
|
| One way to see the difference between telecoms and web is to
| ask yourself when was the last time that you were working on
| a project with an availability SLA of 9 nines (1/3 of a
| second of downtime per year) or even 6 nines (32s per year).
| Some web dev has that, but most doesn't come close, and if
| that's not you then Erlang wasn't built for you (though you
| may still find you like it for other reasons!).
| kybishop wrote:
| Very true it is actually designed for telecoms, but like
| you mentioned the distinction is so small it's not really
| even a stretch to say it is purpose built with at least the
| general architecture of web in mind.
| demosthanos wrote:
| In the grand scheme of things, if we're considering
| everything from web to bridge building, yeah, the
| distinction is small. But within the world of software
| engineering specifically it's not all that small and it's
| worth being precise when we're talking about it.
|
| Whatsapp and telecoms have a lot in common, so no one
| questions that they benefited a ton from the BEAM.
|
| Airbnb, though? The main similarity is that they both
| send large quantities of signal over wires.
|
| Again, none of this is to stop you from liking the BEAM,
| but when we're talking about professional software
| engineering it pays to be explicit about what the design
| constraints were for the products that you're using so
| that you can make sure that your own design constraints
| are not in conflict with theirs.
| throwawaymaths wrote:
| no. in the modern web world you often have persistent
| client server connections, which make it a distributed
| system out the gate. the most inefficient way to deal
| with this is to go stateless, and without smart
| architecture to deal with unreliable connection, it's
| really your best choice (and, it's fine).
|
| since BEAM gives you smart disconnection handling, web
| stuff built in elixir gives you the ability to build on
| client-server distributed without too much headache and
| with good defaults.
|
| but look, if you want a concrete example of why this
| sucks. how much do you hate it when you push changes to
| your PR on github and the CI checks on browser tab are
| still not updated with the new CI that has been
| triggered? you've got to refresh first.
|
| if they had built github in elixir instead of ruby would
| almost certainly have this sync isdur solved. in maybe
| two or three lines of code.
| demosthanos wrote:
| And if you need that kind of persistent immediately
| reactive connection and are willing to pay the price, go
| for it! If that's truly a requirement for you then you're
| in the subset of web that overlaps substantially with
| telecoms.
|
| I'm not cautioning against making the calculated decision
| that realtime is a core requirement and choosing the BEAM
| accordingly. I'm cautioning against positioning the BEAM
| as being designed for web use cases in general, which
| it's _not_.
|
| Many projects, including GitHub, do not need that kind of
| immediate reactivity and would not have benefited enough
| from the BEAM to be worth the trade-offs involved. A
| single example of a UX flow that could be made slightly
| better by rearchitecting for realtime isn't sufficient
| reason to justify an entirely different architecture.
| Engineering is about trade-offs, and too often in our
| field we fall for "when all you have is a hammer".
| Realtime architectures are one tool in a toolbox, and
| they aren't even the most frequently needed tool.
| throwawaymaths wrote:
| "willing to pay the price"
|
| what price? learning a new language that is designed to
| be learned from the one you already know with fewer
| footguns? ok fine.
|
| but you make it seem like going to elixir is some kind of
| heavy lift or requires a devops team or something. the
| lift is low: for example i run a bespoke elixir app in my
| home on my local network for co2 monitoring.
|
| and for that purpose (maybe 300 lines of code? yes, i do
| want reactivity. wrangling longpoll for that does not
| sound fun to me.
| demosthanos wrote:
| To name just a few costs that aren't worth it for many
| businesses:
|
| * A much smaller ecosystem of libraries to draw from.
|
| * Much weaker editor tooling than with more established
| languages.
|
| * An entirely different paradigm for deployments,
| monitoring, and everything else that falls under
| "operations" that may be incompatible with the existing
| infrastructure in the organization.
|
| * When something does go wrong, using a weird stack means
| you have less institutional knowledge to lean on and
| fewer resources from people who've been doing the same
| thing as you.
|
| * A whole new set of foot guns to dodge and UX problems
| to solve related to what happens when someone's
| connection is poor. This has come up repeatedly in
| discussions of Phoenix LiveView--what you get in
| reactivity comes at the expense of having to work harder
| to engineer for spotty connections than you would with a
| request/response model.
|
| * More difficulty hiring people, and an increased
| tendency when hiring for selecting people who are really
| just obsessed with a particular tool and unwilling to see
| when the situation calls for something else.
|
| There are many more, these are just the ones I can think
| of without having a concrete application with concrete
| requirements to analyze. In the end for most apps
| reactivity is so much a "nice to have" that it's hardly
| worth sacrificing the stability and predictability of the
| established option for moderately better support for that
| one aspect of UX, especially given that you can always
| add reactivity later if you need to at a slightly higher
| cost than it would have come at with Erlang.
|
| If reactivity is a core requirement, that's a different
| story. If it's polish, don't choose your architecture
| around it.
| jiggawatts wrote:
| When Jose Valim "moved on" from Ruby development to work
| on Elixir, his fans followed.
|
| It's a bit like true believers switching faiths when
| their leader changes religions.
|
| It's hard to make sense of it from the outside looking
| in, but it's definitely a thing that happened
| historically and occurs in small and big ways even today.
| throwawaymaths wrote:
| i had never heard of jose until i started working in
| elixir. i had about two years of grueling ruby
| experience[0] and boy was elixir an amazing breath of
| fresh air.
|
| what is also a thing is stockholm syndrome and sunk cost
| fallacy.
|
| [0] ok, now that i think about it also this was when ruby
| was having serious 1.84-2.0 transition troubles and i had
| difficulty _reinstalling ruby_ if i needed to redo the os
| because some python wheel broke everything, so i had
| other historical reasons to leave ruby with a bad taste
| in my mouth. i think my gripes about activerecord are
| real, though.
| notjoemama wrote:
| > in the modern web world you often have persistent
| client server connections
|
| Is this actually true though? I'd be interested if you
| know any data backing that perspective. I only know what
| I've worked on and my anecdotal experience doesn't match
| with this statement. But I know my sphere doesn't
| represent the whole. In terms of state, by now there are
| many ways of dealing with persistence and reconnection.
| Not only are most of those problems solved with existing
| technologies and protocols but they're everywhere in web
| dev. Maybe we're talking past each other? Did I
| misunderstand your point?
| tiffanyh wrote:
| Benchmarks of Phoenix vs Rails.
|
| https://www.techempower.com/benchmarks/#section=data-r23&f=z.
| ..
|
| Ranging from 1.5-3.5x faster.
| ksec wrote:
| https://www.techempower.com/benchmarks/#section=data-r23&l=
| z...
|
| I thought to include other implementation from Ruby and
| Elixir. Rails has always been doing much more and on the
| heavier side of things. There are also many test that
| simply by switching server to iodine brings the performance
| to Elixir / Phoenix level.
| pdimitar wrote:
| These benchmarks will be forever amusing. I've done two
| full migrations of a Rails app to Phoenix and the
| differences we've seen in our telemetry boards ranged
| anywhere from 4.5x all the way to 20x.
|
| IMO TechEmpower lost all credibility long time ago after
| it was demonstrated they do nothing against heavily gamed
| benchmarks where people literally do basic string
| matching against regexes instead of doing proper HTTP
| parsing. Some even relied on characters being at exact
| positions.
|
| Add to this how slow they were to adopt normal production
| application code changes to Elixir apps where it was
| proven that the author of the benchmark had no idea how
| to code an Elixir/Phoenix app and yeah, it does not look
| good for TechEmpower.
|
| All that being said, use what you like (some even
| expressed the confusing stance of "I like Ruby's syntax
| more" which, need I even comment how unprofessional that
| is?). But to claim Elixir is just some mere 2x times
| faster than Ruby is misguided. My real production
| experience from the last 10 years says this is bull.
| throw-the-towel wrote:
| What's unprofessional about liking one syntax more than
| another? Of course this shouldn't be the main reason to
| adopt a language, but having a preference is totally OK.
| pdimitar wrote:
| Look in this sub-thread. One person claimed that is the
| main reason for them choosing Ruby over Elixir.
|
| I simply cannot respect that.
|
| Having a preference though? Yeah, absolutely fine. We all
| do.
| bhaak wrote:
| Rails might be 90% better for webdev than the rest while
| Elixir might be 95% better. Talk about diminishing returns.
|
| Add in problems finding developers skilled in Elixir and
| Phoenix and the small available libraries.
|
| Of course, you also have that to some degree in Rails but it
| is much less pronounced.
| kybishop wrote:
| > Add in problems finding developers skilled in Elixir and
| Phoenix and the small available libraries.
|
| Is this actually a problem you see? I'm going on 15 years
| in the industry and haven't seen any issues training people
| up on a new language in just a couple months.
|
| If you need an expert in some library or language to make
| meaningful business progress I feel like that says more
| about whatever tool or language you're using, and I simply
| don't see that with phoenix or elixir in the years I've
| worked with it.
| Vegenoid wrote:
| I feel like the sentiment of "we can train a competent
| dev in our language and stack" has given way to "we want
| a dev with proven experience in our language/stack" over
| the last few years. I suspect this has something to do
| with more non-technical staff being put in between
| candidates and the engineers they'll be working with
| during the hiring process. These non-technical staff rely
| on "x years of experience in thing" to know if a person
| might be competent at that thing.
|
| I think that this is one of the reasons networking is
| becoming more and more important, because it lets a
| candidate demonstrate their generally-applicable
| development skills to a fellow engineer who is capable of
| making qualitative engineering judgements.
| strobe wrote:
| yeah, and sometime it getting really ridicules: N years
| of experience in language doesn't count if no libraries
| from approved list was used.
| lilsoso wrote:
| > Is this actually a problem you see? I'm going on 15
| years in the industry and haven't seen any issues
| training people up on a new language in just a couple
| months.
|
| Some years ago the largest company using Elixir in the
| US, or at least on the west coast, abandoned Elixir
| because they couldn't find enough developers.
|
| Yes. The adoption is poor despite the loud voices.
| ricketycricket wrote:
| That's so disappointing to hear. I have an intern who
| hadn't touched Elixir 4 weeks ago who is already making
| meaningful PRs. She's done the PragProg courses and leans
| a bit on Copilot/Claude, but she's proving how quickly
| one can get up to speed on the language and contribute.
| To hear that a major company couldn't bring resources up
| to speed, to me, shows a failure of the organization, not
| the language or ecosystem.
| bhaak wrote:
| The Ruby on Rails project I'm currently involved in
| doesn't struggle with training people, but rather with
| retaining them. There have been a few instances where we
| trained a junior developer and got them up to speed, only
| to lose them within a year. For small teams, this can be
| quite frustrating and disheartening.
|
| This issue might be partly due to the project being in a
| somewhat niche and conservative industry, so there are no
| startup vibes. However, since they started looking for
| someone ready to make a longer commitment than a
| developer who has just started their career, things have
| improved. But this approach also limits the pool of
| available developers.
|
| It's worth noting that we also use Elixir in this project
| (the chief architect is quite fanboyish about it), but we
| have never had any new developers come in with pre-
| existing knowledge of Elixir.
| pdimitar wrote:
| > _Add in problems finding developers skilled in Elixir and
| Phoenix and the small available libraries._
|
| Since the last 12-15 months, every Elixir job posted gets
| literal hundreds of applications. Just saying.
| sergiotapia wrote:
| Rails has more baked in for the typical crud app. Example:
|
| Try to create a way for people to upload documents like
| images and PDFs and documents. Okay easy enough on both
| platforms and I want you to generate a preview for each of
| those files so that people can easily find those files. Now I
| want you to add pagination. Now I want you to add column
| sorting so that people can sort by file size or by name or by
| upload date. Finally I want you to add a search field. Going
| by the way all of this stuff needs to live in the URL so that
| you can bookmark all the different you know choices you've
| made.
|
| The stuff is pretty trivial and rails but in elixir you would
| have to bake it all yourself very boring code that doesn't
| really matter. This is why I chose to build my startups admin
| dashboard in rails despite our main production API being an
| elixir.
| sanswork wrote:
| Check out ash-hq.org they are basically building the data
| side framework to handle all those things and it works
| great with Phoenix.
| sergiotapia wrote:
| Extremely risky tbh I would have an extremely hard time
| if I go off path or need to hire someone. It would be
| almost negligence to choose it unfortunately
| sanswork wrote:
| It's the opposite since it standardises everything as
| oppose to roll your own.
|
| If you need to hire someone you'd need to train them on
| your system no matter what, with a framework you can use
| their documentation to explain where things are and how
| they work.
| sergiotapia wrote:
| Elixir is already a small fraction of a small and
| shrinking community (Rails). Ash is a tiny fraction of an
| already tiny fraction. I cannot imagine defending this
| choice to anyone unless I was literally the CEO of a
| company and answered only to myself.
|
| Ash does look badass though!
| arrowsmith wrote:
| Elixir really needs to lose the perception, if there is
| one, of it being a subset of the Ruby/Rails community.
| It's true that the initial influx of Elixir developers
| came from the Ruby world back when Elixir was new, but
| that was a long time ago. Tons of Elixir folk come into
| it nowadays without a Ruby background.
|
| Elixir and Ruby really aren't that similar anyway. The
| syntax differences are very superficial - Elixir's a
| functional language with very style and semantics to
| Ruby, and that's even before you get into the magic of
| OTP and the BEAM, for which Ruby has nothing comparable.
| borromakot wrote:
| I've been using Elixir for over 10 years, if it was ever
| a "small fraction of the Rails community" it was during
| its formative years only. Elixir is fully its own thing.
| We don't even really talk about Ruby? I really do think
| you've got a mixed up perception on that front
| arrowsmith wrote:
| Even Jose himself says that Ruby's influence on Elixir is
| overstated: https://news.ycombinator.com/item?id=36604054
| sanswork wrote:
| It doesn't really matter though. You have to train new
| staff on your systems/code base no matter what you use.
| So if they don't already know ash it's the exact same as
| if you didn't use it. Only now you can point them at the
| ash docs and buy them the ash book and they'll know where
| everything in your system goes.
| ricketycricket wrote:
| LiveView uploads are baked in, previews and all. Everything
| else you list is included in the Flop library, if you want
| something off the shelf. In rails you are still including
| Kaminari or whatever other gems for all this too, so this
| is really no different.
| AstroBen wrote:
| If you're looking for something to invest in for the long
| term I think Rails wins by a mile. They have the funding,
| investment and strong companies dependent on it to keep it
| marching forward - both the framework and surrounding
| libraries
| bee_rider wrote:
| Fortran nowadays is fairly ergonomic and modern.
|
| In terms of successors there's maybe Julia, or otherwise
| you'd have to use Python or Matlab/Octave, with all that
| going to a scripting language entails. In any case it doesn't
| really feel like there's been a replacement.
| princevegeta89 wrote:
| I have a very extensive experience with both Ruby on Rails
| and Elixir/Phoenix. Also ended up building large full-stack
| apps on either framework.
|
| In the beginning when Ruby on Rails said hello to me, I
| instantly fell in love with it and the simplicity and the
| natural semantics that flow with it. It was absurdly easy to
| write new features and ship them to production. As the
| codebase grew and the team grew we started running into
| situations where APIs broke, or to trace the workflow of
| things in terms of finding where methods came from, finding
| parent modules of modules, and finding their parents,
| configuration, and I started to note a general lack of IDE
| autocomplete and type-safety.
|
| Then after a few years I jumped ship to Elixir and if felt
| like a breath of clean air when I had to learn FP. Everything
| was simple enough to understand. Performance knocks Elixir,
| Node, Python and any other interpreted stack out of the
| water. The Phoenix framework was, and is said to be
| thoughtfully designed and although there was no IDE support,
| we still had Elixir LS which was great enough to provide
| realtime guidance, linting and type safety during compile
| time. I was able to ship a very large app into production and
| it was bulletproof. The problem with Elixir was our other
| engineers struggled to shift away from Node, or any other
| stacks they already knew. They found the entire FP world to
| be weird. Hell, I found it weird too at times. Simple
| mutations of maps and arrays, that would be trivial in Ruby
| ended up being so complex in Elixir. In the end it felt like
| my team was not on the same page. I guess Elixir would be
| great if you ran a 3-person team or something, but since we
| were not, we got back to Ruby. In today's world though, I am
| largely looking at Go, for a backend system. IDE support is
| up there with Java, and the ecosystem is old and mature
| enough to find any package that you look for. Performance is
| C-like and learning curve is lean.
|
| Just my 2c with all these platforms.
| LanceH wrote:
| I was working with Go a lot as something complementary to
| Ruby/Rails. I have ended up with so much Ruby work. Either
| maintenance of large successful efforts from years ago, new
| development for those same companies, or new development
| from the people who have experienced great success with
| Ruby on Rails. I can't seem to get away from it, and that's
| just fine.
|
| At this point, I putting together teams and getting new
| developers into Ruby on Rails. I'm also seeing companies
| move _back_ to full stack RoR after the luster of React has
| worn off. Also, modern RoR can get you so far now with a
| fraction of the dual framework headaches of a RoR backend
| /JS frontend.
| princevegeta89 wrote:
| Great to hear. I agree - all the react/SPA bloat along
| with other layers like Vite/SSR/Webpack etc. is not
| needed for 95% of the apps today.
|
| Any MVC framework with HTMX, JQuery
| (yes)/Hotwire/Stimulus/Turbo, etc. puts the productivity
| and deployment speed of the front-end setup above to
| extreme shame.
| poisonta wrote:
| Elixir is a great language, but it lacks a framework as
| polished and full-featured as Rails. Phoenix could have been
| far more popular if it had something like Active Record.
| burnt-resistor wrote:
| Ecto
| pmontra wrote:
| Ecto was literally the component I liked less in all the
| Phoenix stack when I worked with it after a dozen of
| years of Rails.
|
| I did maybe 5 years of Phoenix for a customer of mine and
| went back to Rails for another customer. It's good enough
| and overall Rails is easier to deploy IMHO. Capistrano vs
| I don't remember what.
| kybishop wrote:
| Oh man, this must just be subjective because I find Ecto
| to be beautiful compared to the absolute trainwreck of
| Activerecord. Having compile time guarantees through Ecto
| is wonderful.
| pmontra wrote:
| Yes, that must be the case because if my customers and I
| would care about compile time guarantees we would not be
| working with Ruby.
|
| In that years long Phoenix project one of the developers
| on the team added dialyzer type annotations to the
| functions in the files he worked on. Everybody else did
| not bother. The project ended up with no type checking.
| The service run and the company did well.
|
| Overall using Phoenix was a good experience. I never used
| Elixir in any other project and never for my own
| programs. I use several other languages for my own little
| scripts, mainly bash, Ruby, Python and Lua. I think that
| I really like dynamic typing.
| poisonta wrote:
| Many Rails developers try Phoenix at some point because
| they may need better performance. They're so accustomed to
| the Rails structure that they assume Rails has done
| everything right. However, Ecto and ActiveRecord are two
| very different beasts. When Rails developers try out Ecto,
| they often feel there's too much boilerplate and believe
| the Rails design is much more intuitive. This, I think, is
| one reason Phoenix struggles to attract Rails developers.
| If it can't please Rails users, it will rarely appeal to
| others.
| burnt-resistor wrote:
| It'd be nice if IEx command history search and recall worked,
| but it doesn't. ):
| mattl wrote:
| Where is the 15 min make a simple blog with minimal code
| video for Elixir?
| ricketycricket wrote:
| Twitter clone in 15 minutes:
| https://www.youtube.com/watch?v=MZvmYaFkNJI
| mattl wrote:
| Thanks for the link, Rickety Cricket.
| guywithahat wrote:
| As someone who has used elixir for startups and loves it, the
| benefit of Rails for a startup is that it's easier to pick
| up. html/live projects can create more confusing layouts,
| which can make it harder to learn if you're trying to get
| something running. Rails is a great framework to use if
| you're primary product is not a website, but you need a
| website.
| neya wrote:
| I was a Rails consultant for about 7 years. Then, I switched to
| Phoenix - really out of just curiosity. Since then, I've never
| looked back. If you never believed in "Simple is better"
| philosophy, you will after using Phoenix. The development time
| is shorter, the bugs are far less since you catch them at
| compile time and the development experience is unmatched. Oh,
| and did I mention performance? You can get insane performance
| just out of the box.
| nopcode wrote:
| I keep reading about a shortage of phoenix jobs. Any advice?
| monooso wrote:
| I wouldn't describe LiveView as simple, necessarily. It makes
| for a great demo, but in my experience it complicates simple
| things in lots of subtle--and occasionally pernicious--ways.
|
| Whilst you can use Phoenix without LiveView, this is becoming
| increasingly difficult as the Phoenix developers have clearly
| decided that LiveView is The Way.
| maqnius wrote:
| +1 from me. I already spend more time learning phoenix in
| my free time than I'd like to admit and I'm stil waiting
| for the moment it makes 'click'.
|
| It's just so hard sometimes to wrap your head around the
| abstractions, even though they are shallow + things are
| changing fast. I feel like my django-ish mental modal of
| web applications is also getting in the way a lot.
|
| It would probably help, if I could spend more time with
| less interruptions on it. But I have to say that I expected
| to get into it a lot quicker since it's praised so much for
| it's dev experience.
| arrowsmith wrote:
| Shameless self-plug: if you're struggling to learn
| Phoenix maybe I can help?
|
| https://learnphoenixliveview.com
| neya wrote:
| I never mentioned LiveView in my comment, just Phoenix (you
| can use Phoenix without LiveView). But, in defense of
| LiveView, I use it in production - however, you will need
| something to compliment it for sure - I use Svelte 5, which
| is great. LV has a learning curve, but it makes development
| so much better once you get the hang of it, tbh. May need
| some 2-3 projects to get used to it. My $0.02.
| monooso wrote:
| FWIW, I've been using LV in production for five years. My
| comment stands.
| camcil wrote:
| What caused the drop in popularity in RoR? It seemed like
| ~10-12 years ago RoR was the de-facto startup standard. On any
| given day there were multiple items on the HN front page having
| something to do with RoR.
| AstroBen wrote:
| the allure of the new and shiny
| vinceguidry wrote:
| NodeJS and the siren's song of using the same language on the
| server as the client.
|
| Despite the popularity, node never caught up with rails in
| terms of features and productivity. I was part of a
| replatforming from rails to node some 10 years ago. So many
| things we had to just rewrite because there was no option at
| the time in node. The team lead that made the decision left
| half-way through the project. Second worst thing to happen to
| me in my career, after covid of course.
| Spivak wrote:
| Well and that JS is really fast thanks to V8 and TS has
| leapfrogged Ruby in terms of developer tooling. Personally
| I think Ruby is a nicer language and JS has a lot of odd
| quirks but it became Java. A good natural choice that can
| be used for any project.
| vinceguidry wrote:
| > leapfrogged Ruby in terms of developer tooling
|
| The only thing I would ever want from js is destructuring
| assignment. There's rightward assignment in ruby now but
| it's pretty clunky.
|
| > became Java
|
| Best laugh I've had all week.
| ksec wrote:
| Performance, scalability or ultimately cost. Remember 10 - 15
| years ago when Twitter was using Ruby it was a lot slower.
| Even without YJIT CRuby today would still be 2 - 3x faster
| than then. Tooling wasn't as good, Hardware were a lot more
| expensive at the time. So when you have news spread out about
| how RoR cant scale cheaply, they jump to newer and shinier
| things like Node.
|
| I would guess running RoR today is 100x cheaper than 10 years
| before. And will continue to improve as we get ZJIT or
| running on top of JRuby.
| vidarh wrote:
| When Twitter was using Rails it was also using a totally
| broken architecture that was way too centralised. Their
| replatforming also involved rearchitecting.
| kubectl_h wrote:
| * Node bringing JS to the backend.
|
| * Python won in data science/analytics and AI/machine
| learning
|
| * Python also seems to be the high level language used most
| in academia for non CS engineering (and CS too)
|
| Rails continues to be relatively popular in early stage
| companies. Plenty of well known companies started with Rails
| in the last 10+ years and it continues on as part of their
| stack.
| timr wrote:
| > What caused the drop in popularity in RoR? It seemed like
| ~10-12 years ago RoR was the de-facto startup standard. On
| any given day there were multiple items on the HN front page
| having something to do with RoR
|
| New things are "simple", and old things are inevitably
| complex, which _always_ attracts the new generation of
| inexperienced coders (I include myself in this). This
| continues until all of the complexity of the domain are
| captured in the "new" thing, and the cycle begins again.
| Rails is vastly more sophisticated than when I started using
| it in ~2007, when things like CSRF attack mitigation weren't
| even built in. So it's a better framework now, but you have
| to understand a lot more to get started.
|
| Also, from ~2012 until recently, bootcamps have been pumping
| out new programmers who _only_ know Javascript because it was
| possible to do a full-stack web app with JS, and the
| bootcamps would rather not teach another language.
| closeparen wrote:
| Mobile came on scene, which meant you wanted an API, which
| split web development into backend and frontend. At the same
| time, the powerful-but-crusty complexities of enterprise Java
| backend world, which Rails stood in opposition to, started to
| get more lightweight and fashionable answers in the
| Go/Kafka/gRPC/microservices scene. While a very convenient
| overall development experience, it didn't stack up as well
| when considered in isolation as either a backend or a
| frontend technology. Much of the Javascript integration it
| has today (Turbo, etc) came after people had already moved
| on.
| mrinterweb wrote:
| Around that same time, microservice architecture was the new
| hot. Rails apps tend to be monolithic. Now that many people
| have realized that microservice architecture is often not
| worth the complexity costs, monolithic apps are back in
| fashion, and people are rediscovering how great rails is.
| jupp0r wrote:
| Rails is in steady decline [1].
|
| [1] https://trends.google.com/trends/explore?date=all&geo=U
| S&q=%...
| jupp0r wrote:
| > What caused the drop in popularity in RoR?
|
| Async/await. JavaScript and all other modern languages and
| frameworks have a great concurrency story. Rails still hasn't
| (but it's coming next year, it's been coming next year for a
| decade).
| speleding wrote:
| The concurrency story in Ruby is fine. We've been using
| multi-process Ruby scripts in production for over a decade.
| The pre 2.7 ruby had some issues, but it's been solid for
| years. The async/await programming paradigm is painful by
| comparison. Sure, there are languages out there that have
| been designed from the ground up with concurrency in mind,
| that have an even better concurrency story, but those do
| not put developer happiness((tm)) front and center.
| matt_s wrote:
| With so many generative AI tools out there, picking more
| obscure or niche languages is a detractor because the AI models
| won't have as much depth of training to pull from when you ask
| it to do things.
|
| Also, technology choices for B2B web apps is rarely going to be
| a sole factor in determining success or failure of any
| business. As much as this community likes to compare
| performance metrics, benchmarks, frameworks and everyone has
| personal tastes on what is "good", all of those discussions are
| mostly irrelevant. Picking something the team is comfortable
| with and has depth of knowledge in is a good practice.
|
| So just pick Rails and move on with solving business problems
| :)
| runjake wrote:
| I do some Rails work and I've found that Ruby and Rails are
| one of generative AIs weaker languages. I usually get pretty
| shoddy output[1].
|
| I generally don't use AI during Rails stuff, other than as a
| hint for a Google search or a docs lookup.
|
| Are you having a different experience?
|
| 1. Shoddy output with Ruby and Rails knowledge. In general, I
| would consider myself pretty advanced with "prompt
| engineering".
| matt_s wrote:
| I'm not expecting perfect output, if there is such a thing.
| I'm expecting output equivalent to a junior engineer or
| intern at this point in time. I can tell an agent in the
| editor I want it to add a many to many join relationship
| and a multi select field to a form and it does it pretty
| decently. In some ways this is more automating the tedious
| tasks which is really what AI's strong suit is right now,
| in my opinion. Sure I could go move a method around,
| refactor the 5 classes that call it, etc. but I can
| delegate that task and its done in a few seconds while I
| think about the next thing I want to do.
|
| I find if you get too lengthy with tasks or too advanced AI
| goes off the rails so to speak, sorry for the pun.
| azuanrb wrote:
| Similar experience. Although, recently just tried Claude
| Code and it seems to be a pretty good upgrade (both Sonnet
| and Opus). I'd suggest you to give it a try if you haven't.
| For UI, Playwright MCP helps a lot. And since it can run
| rspec too, it can get faster feedback.
|
| To me it is better now, but not as good as certain
| languages. Since that I'm using Go as well, I do notice
| Claude Code perform better with Go.
| ukprogrammer wrote:
| I've found that OpenAI models write fantastic Rails code,
| having a deep understanding of Rails codebase conventions.
| Anthropic's models do seem to have a very hard time writing
| Ruby in general.
| Hnus wrote:
| Serious question: do people actually enjoy writing Ruby? I feel
| I'm writing in something like Bash. I never felt this way until
| I picked up other languages like Rust, Zig, C#, and learned a
| tiny bit of programming language theory. After that, the loose
| and squishy feel of Ruby really started to bug me. Also, it
| seems like every Ruby programmer I know only ever uses other
| dynamic languages like Python. It's never like they're experts
| in C++ or something and then decided to start programming in
| Ruby.
| PapaPalpatine wrote:
| What an odd question lol. Yes, people like writing in Ruby.
| I'm one of the. Switched from C# in 2016.
| Hnus wrote:
| You don't miss things like enums, exhaustive switch or any
| other basic language features? How about `method_missing`
| its such a crazy idea to me that something like this
| exists, I know why it exists but I am like why, why such
| bloat and complexity.
| PapaPalpatine wrote:
| No, I honestly don't. I can emulate an Enum without
| having an Enum type. I rely less on a compiler and more
| on myself with automated tests.
| andrekandre wrote:
| > rely less on a compiler and more on myself with
| automated tests
|
| jme, but i think this is a muscle that a lot of people
| don't have developed if they came from a
| language/toolset/ide that does automatic type checking
| and autocomplete reliably etc
| adhamsalama wrote:
| Part of the problem is when you have to rely on someone
| else.
| rubyfan wrote:
| Can you elaborate on why you think method_missing is
| bloat?
| Hnus wrote:
| As another commenter said,
|
| > it's about your taste and philosophy.
|
| Personally, method_missing goes against both of mine. It
| makes programs harder to reason about, more difficult to
| debug, and nearly impossible to `grep`. That said, I
| understand that this kind of flexibility is what some
| people like. I just don't.
| RangerScience wrote:
| Ruby inheritance is a list of class names. When you call
| a function on an object, Ruby goes up that list, looking
| for the first one that defines that function.
|
| If it doesn't find any class defining that function, it
| calls `method_missing` (and again, goes up the list). The
| Ruby base object class defines `method_missing`, so if
| no-other classes in the ineritance list do, you get that
| one (which then throws the usual error).
|
| IMO, there is zero bloat or complexity added by this;
| it's super simple language bootstrapping (allowing more
| of Ruby to be written in Ruby, vs the c interpreter).
|
| What do you see as the bloat and complexity added by
| this?
| hotpocket777 wrote:
| > Also, it seems like every Ruby programmer I know only ever
| uses other dynamic languages like Python. It's never like
| they're experts in C++ or something and then decided to start
| programming in Ruby.
|
| Can you expand on what you're saying here or why you're
| raising this is as an issue with ruby the language or rails
| the library?
| Hnus wrote:
| Just a personal observation that made my communication with
| ruby developers hard as I cannot use concepts from strongly
| typed languages because they live in a word without them,
| but I guess it's more issue with me than them.
| monooso wrote:
| There are several people earlier in this very thread who
| moved from C++ to Ruby.
| helloguillecl wrote:
| I love Rails, its been my to-go framework for reference. But
| I could never get as confortable with Ruby as writing JS or
| PHP. I do not know the reason.
| quest88 wrote:
| I agree. I think..there's too much freedom. Too many ways
| to do things, and debugging is hard with monkey patching.
| AstroBen wrote:
| Can you give an example of where monkey patching made
| debugging hard? I have a decade of Ruby experience and
| can't think of a single time it was an issue
|
| This is one of those things that _sounds_ like it 'd be a
| problem but it really isn't
| vidarh wrote:
| If debugging is hard to you in Ruby because of monkey
| patching, it's an issue of not knowing the debugging
| tools. Attach pry or Ruby debug, and show the source
| location of a method, or log them. This isn't surprising
| - debugging Ruby is different to debugging most static
| languages, and more tutorials on how to do this well
| would be nice...
|
| Also the use of monkey patching in Ruby peaked something
| like a decade and half ago. Outside of Rails, it's
| generally frowned on and introducing new methods is
| usually addressed by opting in by including modules these
| days.
| ukprogrammer wrote:
| Agreed, it still absolutely astounds me the number of
| developers out there that do not use a debugger as an
| essential part of their toolkit.
| rubyfan wrote:
| Yes, many people love programming in Ruby. It's a matter of
| preference not some lack of technical merit. There are plenty
| of people who are well equipped in strongly typed languages
| that write in both. You might not know them but you really
| don't have to look very far.
| tuyenhx wrote:
| Yes. I do. I enjoy ruby so much.
|
| After 10 years working with Java. Now I dont wanna go back
| anymore.
|
| It is about your taste and philosophy. I dont think it
| related skill issue.
| the_lonely_time wrote:
| I spent more of my life that I would like to admit learning
| and writing Rust. I still build all of my web applications in
| almost pure Ruby these days. Speed of thought to action is
| simply unparalleled and it turns out in most situations that
| was the most important factor.
| mrinterweb wrote:
| I had a good background in C++ programming before switching
| to ruby. At first, I was terrified of the lack of strict
| typing, but after using it for a while, I realized my concern
| wasn't that warranted. For me it is about the tradeoff of
| dealing with types vs productivity. Sure I occasionally get
| bit by a random "method not defined for nil" error, but it is
| usually very easy to fix, and I don't run into the issue very
| often. With ruby, and especially rails, it is about the
| productivity gains. I can simply accomplish much more in less
| time and fewer lines of code than I would in other
| languages/frameworks. Not only am I writing fewer lines of
| code (usually), the language is very expressive without being
| overly cryptic. The code is more readable, and to me that
| results in better maintainability. The strong community and
| ecosystem emphasis that is put on testing, also leads to more
| resilient and much more maintainable code.
| maximegarcia wrote:
| I do. It's a whole thing that get you down to writing your
| business logic in an expressive way very easily. Framework
| (Rails) helps, yes, but even pure Ruby can be nice. I've
| written a second time accuracy simulator for cars and
| chargers in a EV charging stations in pure Ruby, that was
| fast to iterate around and pleasant to write.
|
| The ecosystem, toolchain and all do a lot. It is really
| missed when I do other languages, and I wish to find the same
| way of developing elsewhere. I currently do C for embedded in
| an horrible IDE, and I want to bang my head against the table
| each time I had to click on something on the interface.
|
| (btw Python is a nightmare for me)
| timewizard wrote:
| That's not a serious question. Of course people do. Your
| inability to understand the language does not impact anyone
| else other than yourself. This should go without saying.
|
| I'm also an expert in C, Go and JavaScript. Ruby is an
| excellent language and the smalltalk paradigm has some real
| strengths especially for duck typed systems. The only reason
| I don't use it more often is because it is slow for the type
| of work I'm doing recently.
|
| It was amazing for web work and it's fantastic for writing
| small little utility scripts.
|
| A open distaste for things does not make you sophisticated or
| smart. You're not in any category of high repute when you do
| this.
| vidarh wrote:
| Yes, love it. Rewritten large parts of my stack in it
| (editor, shell, font renderer, terminal, window manager, file
| manager)
|
| I started from a background of heavy C++ use, including a lot
| of template metaprogramming. Convincing me to even give Ruby
| a chance took a lot, but once I'd tried it I abandoned C++
| pretty much immediately, and don't miss it.
| zem wrote:
| yes, I have used a lot of languages, both static and dynamic,
| and ruby is one of the ones I love. maintaining large code
| bases is certainly not its forte, but in terms of expressing
| what you want in code it is like a tool that fits really well
| into my hand.
| the_fury wrote:
| Absolutely. I enjoy it so much that I wonder "do people
| actually NOT enjoy writing Ruby?" It's usually the first tool
| I pull out of the toolbox for DSLs, scripts, spikes, one-offs
| and the like. A lot of the time, the project will happily
| stay in Ruby unless there's a good reason to use something
| else. And then I move it - horses for courses.
|
| I programmed professionally in C, C++, C#, Deplhi, and a few
| other languages well before I had even heard of Ruby.
| IshKebab wrote:
| Can you tell me why exactly? I've never used Rails but I have
| tried to understand and modify Gitlab's Ruby code and honestly
| it was a completely incomprehensible mess. I'm no stranger to
| large codebases but Gitlab is almost impossible to follow and
| it seems to be entirely because they use Ruby.
|
| I mean if you look at one file the code seems fairly clean and
| well written, but if you try and figure out e.g. where a
| function is called from... well good fucking luck! There's no
| static typing to help you, and even worse it seems like almost
| everything is "magically" connected. Like you'll have a
| function called `foo_bar()` and if you grep for that you get
| zero results. In the end you'll find that in the `Foo` class
| there's a list of strings including `BAR` and it constructs the
| identifier from those.
|
| Absolute nightmare. But people do seem to love Rails... so why?
| vidarh wrote:
| Learn to use a remote debugger, and how to show the method
| source location.
|
| This may sound snarky, but it's a good faith suggestion. Ruby
| has all of the tools to make debugging easy, but they're
| different than what you will expect if you come expecting
| things to work like in the static typing world.
|
| But as much as I love Ruby, I do agree that Rails has too
| much unnecessary "magic". Much of which more modern Ruby is a
| reaction to. Personally I avoid Rails for my Ruby web
| projects.
| IshKebab wrote:
| I mean... that sounds like a pretty horrible dev
| experience. Every time I want to understand a piece of code
| I have to actually run it? Insane.
|
| For example I'm trying to understand Gitlab's merge train
| behaviour. Do I have to set up an entire Gitlab instance
| from source, then create a project, set up CI, run a merge
| train, all while running Gitlab in a debugger and then set
| a breakpoint and then _finally_ I can see where the code is
| called from?
|
| I've also done a lot of work on VSCode which is similarly
| large but mercifully written in Typescript. For that I just
| right-click->find all references. It takes 3 seconds.
| vidarh wrote:
| In practice it is not. And no, you don't have to run it,
| but it makes things a lot easier to do so.
|
| And no, you don't need to do what you suggest, you just
| need to _load all the code_ into a running Ruby REPL.
|
| It is one consequence of Ruby being as dynamic as it is,
| but another is that the codebases tends to be far
| smaller. Anywhere from half to 1/10th of the size of
| codebases in statically typed languages is my experience,
| including with direct translations.
| IshKebab wrote:
| > load all the code into a running Ruby REPL
|
| That counts as running it if you ask me. And I don't see
| how just loading the code would help you find the callers
| of a function?
|
| > Anywhere from half to 1/10th of the size of codebases
| in statically typed languages is my experience, including
| with direct translations.
|
| That sounds highly implausible.
| vidarh wrote:
| > That counts as running it if you ask me. And I don't
| see how just loading the code would help you find the
| callers of a function?
|
| Loading it lets you introspect the code for calls. It's
| not necessarily always trivial to know what the type of
| the target object will be unless you're prepared to
| execute candidate methods, but it's rare for this to be
| an actual issue in practice. The more typical way of
| doing this _would_ be to call piece of the code _but
| without_ the elaborate setup you argue you 'd need.
|
| You can also use Ripper or Parser to analyse the code if
| you insist on not loading the code, but you're then
| making things harder for yourself for no good reason.
|
| And that's really what it boils down to: If you insist on
| doing things the way you would for a static language,
| then yes, you will have a bad time.
|
| That's a you issue, not a tooling issue.
|
| > That sounds highly implausible.
|
| It's nevertheless true. I've translated multiple projects
| feature for feature from C, C++ and other languages to
| Ruby over the years. It's only implausible to people
| inexperienced with Ruby.
| IshKebab wrote:
| > The more typical way of doing this would be to call
| piece of the code but without the elaborate setup you
| argue you'd need.
|
| But how do you call the code if you don't know where it's
| called from?
|
| Let's have a concrete example. In this `initialize`
| method how do I know what the arguments are meant to be?
|
| https://gitlab.com/gitlab-
| org/gitlab/-/blob/master/lib/gitla...
|
| There's no type annotation so the main ways to know are
| documentation (haha) and seeing what it is called with in
| existing code. But how do you find where that method is
| called?
|
| (Note this isn't the best example because I would imagine
| the `initialize` isn't magically generated, but it is
| still difficult to search for so it's almost as bad as
| the magic identifiers.)
| ukprogrammer wrote:
| I echo the sentiment that you MUST use a debugger when
| working with ruby/rails. When using a debugger, magic becomes
| a call stack that is transparently visible. Once proficient
| and familiar with the conventions, reading it becomes a lot
| easier.
|
| For Rails's productivity, there's many reasons. One is the
| 'Active Stack' which acts as a 'standard library' of sorts
| for the framework.
|
| It provides extremely seamless tooling all the way from the
| most frontend of concerns (ActiveView - HTML/JS) to the
| backend (ActiveRecord - SQL ORM layer) and anything in
| between (ActiveController - HTTP Requests, ActiveMailer -
| Emails etc.). These tools are simple, robust and cohesive.
|
| These primitives are built on by the community to provide
| powerful tooling (Devise, OmniAuth, amongst others) that
| allows one to implement the standard plumbing most SaaS/CRUD
| apps need in a few minutes - billing, auth, emails so you can
| get to writing business logic in a few minutes and have the
| boring stuff solved quickly.
|
| Implementing just these basics in JS can take many hours and
| have you scratching your head wondering "Why are there 20
| different ways to implement X? Why is there no tried and true
| way for something that are surely been done thousands of
| times? Why hasn't someone abstracted these details all away
| yet? Why do I have to npm install for this basic
| functionality? Wait, why did my build tooling just break?"
| IshKebab wrote:
| So basically it's that it comes with built in libraries for
| common tasks? Authentication is definitely a super annoying
| thing to have to set up manually so I can see the
| attraction there.
| nisa wrote:
| You are not alone. Joined a company with a rails codebase and
| I really came to hate convention over configuration if you
| are not familiar with the convention. I've found Ruby on Roda
| and dry-rb much more understandable. I guess it's really a
| matter of taste. I've did C++ and Java before and while I
| appreciate Ruby rails is too much magic for me. I also hate
| to run into errors in runtime that a typed language would
| have catched.
| mvdtnz wrote:
| The idea that Rails productivity is "unmatched" is such a
| holdover from 13 years ago. You can like Rails all you want but
| it is very much matched by several quality frameworks today.
| Many of which don't suffer from Rails' very real downsides.
| RangerScience wrote:
| > several quality frameworks
|
| Gonna name names? :)
| deedubaya wrote:
| As with all security audits, most findings are a balance between
| risk and usability.
| dzonga wrote:
| and yet people wanna shit at frameworks.!! by choosing something
| like Rails or another major popular web framework -- you have
| already mitigated a lot of security vulnerabilities that affect
| the industry. & no next.js is not a proper web framework. JS
| doesn't have the equivalent to rails.
|
| The web frameworks we're talking are Rails, Django, Laravel &
| Spring.
| runjake wrote:
| "Equivalent to Rails" is a nebulous term, but given your
| examples, I'd offer these as JS equivalents of Rails:
|
| - SvelteKit
|
| - RedwoodJS
|
| - Wasp
|
| There are more options but I think they'd cause more "well,
| actually" comments than I could bear. :-)
| frou_dh wrote:
| Let's take a look at SvelteKit. Huh, it has _zero_ to say
| about the database? And this is the first framework that
| comes to mind as equivalent to Rails? Sheer insanity
| ostif-derek wrote:
| Hey there everyone!
|
| Some friends just notified us that this is trending.
|
| Let me know if you have any questions/comments/feedback about the
| work! It was a great project, I wish we had more budget so that
| we could spend some time with ruzzy and the C extensions as
| there's probably some things to be unearthed there with ASAN and
| UBSAN.
|
| As for the comments on Spring/Elixir/Django/Phoenix, they're on
| our wish list every year but we're always limited by funding.
| It's about what the communities, foundations, and agencies can
| and will support. We are always working toward getting larger
| grants where we can work fully independently on whatever we want,
| but so far that hasn't materialized.
|
| We'll keep trying!
| RKFADU_UOFCCLEL wrote:
| I had no idea people could hack my forum by applying the
| system("wget hacker.lol") transformation to their profile image.
| Thanks for the find!
| jensenbox wrote:
| Is there a place where I can pay to fund a Django audit? I would
| gladly contribute.
| kelseydh wrote:
| It's funny that Rails generates params for parameters passed to
| it for GET, HEAD and DELETE requests, even though it shouldn't. I
| think I've noticed this before when debugging but never thought
| much of it. In a poorly coded application (e.g. globally
| detecting params on in a `before_action`) it definitely could be
| become an issue.
| inopinatus wrote:
| Some good recommendations. Feedback on this one:
|
| > "X41 recommends to disallow the creation of un-escaped
| SqlLiteral objects with user input in favor of a complete model
| of SQL"
|
| Rails already has a sufficient model of SQL in its Arel layer.
| Complete? Not exactly, because SQL is never implemented by the
| standard, but certainly sufficient, and very composable and
| extensible. Sadly the core team killed off the public
| documentation of Arel a few majors ago. Nevertheless I still use
| Arel whenever Active Record doesn't expose enough of the model,
| such as expressing left-open intervals as inequalities1.
| Sometimes incorrectly called a "private API", but it's not
| anyone's private possession, Arel is just undocumented in recent
| releases.
|
| The recommendation's language is also just a touch naive, because
| it's nigh-impossible to outright disallow developers doing
| practically whatever they want to in Ruby, there's no isolated
| sandbox. The question is what incentives are in place to stop
| them wanting to.
|
| Active Record already has excellent support for bound values via
| the predicate builder, and it's only egregiously bad code that
| concatenates raw user-supplied values directly into query
| strings. Nevertheless for those few remaining places in the API
| where this could happen inadvertently such as #calculate, a
| variant recommendation - similar in spirit, but not identical -
| might be that where it doesn't already, Active Record treats raw
| strings supplied as requiring escape unless explictly wrapped
| with Arel.sql(), or just accept an Arel node/AST (many already do
| on the QT). That is, force the developer to confess their sin in
| writing, or do it relationally.
|
| But IMO the wizards shouldn't keep Arel locked up in the tower,
| either.
|
| [1]
| https://gist.github.com/inopinatus/c84c78483b30fb2d5588db9be...
| josephg wrote:
| > The recommendation is also a touch naive as framed, because
| it's nigh-impossible to outright disallow developers doing
| practically whatever they want to in Ruby
|
| Sure but defaults matter.
|
| Nothing is truly private in most languages. In C/C++, you can
| poke raw memory. In rust you can transmute. In Java you can
| override the classloader and edit classes before they're passed
| to the JVM and so on. But most environments have a golden path
| for getting things done which most developers will walk. This
| is exactly what removing documentation does - it signals to
| developers that some API isn't part of the expected golden
| path.
|
| Every sql library needs ways to pass raw sql strings to the
| database. (Just as every browser framework needs a way to embed
| raw html strings). But it should require you to explicitly
| acknowledge you're doing something unsafe. Rust's unsafe
| keyword. React's unsafelySetInnerHTML, and so on. It's not
| about denying it. It's about making the obvious thing safe and
| the unsafe thing not obvious.
___________________________________________________________________
(page generated 2025-06-16 23:02 UTC)