Live data from Hacker News

Finding relationships between Ruby’s top packages and their dependencies

shopify.engineering

11–20 of 48 posts

Re: Finding relationships between Ruby’s top packages and their dependencies

#11
post #3

Aside from Shopify and others from that era, what modern SaaS offerings are choosing Rails (or Ruby) for their main app? I had one last peer still using Rails, and since Heroku's been on the ropes they're out. Other than DHH adherents, is anybody still excited about Rails? To draw an even smaller circle, is anybody still excited about Ruby when Rails isn't involved?

Been using Rails since 1.2. Still excited. Rails 7 + Hotwire + ESBuild = Once I add bootstrap and simple_form, the amount of code I don't have to write in a Rails application is just incredible.

And yes, I've used other things on and off my entire career. React is a love/hate relationship. Happy to punt it when working on a small project.

Re: Finding relationships between Ruby’s top packages and their dependencies

#12
I'm pretty convinced Ruby and Python's package ecosystem has most of the same problems of JavaScript's but it's just not talked about as much. This article definitely has a lot of similarities to npm's MFA implementation and security concerns that have come up.

Re: Finding relationships between Ruby’s top packages and their dependencies

#13

I'm pretty convinced Ruby and Python's package ecosystem has most of the same problems of JavaScript's but it's just not talked about as much. This article definitely has a lot of similarities to npm's MFA implementation and security concerns that have come up.

As it happens, folks from RubyGems, PyPI, npm and others meet regularly to discuss common problems and share ideas: https://github.com/ossf/wg-securing-software-repos

Re: Finding relationships between Ruby’s top packages and their dependencies

#14

I'm pretty convinced Ruby and Python's package ecosystem has most of the same problems of JavaScript's but it's just not talked about as much. This article definitely has a lot of similarities to npm's MFA implementation and security concerns that have come up.

As it happens, folks from RubyGems, PyPI, npm and others meet regularly to discuss common problems and share ideas: https://github.com/ossf/wg-securing-software-repos

That's not very surprising. I think what's surprising is the perception of RubyGems, PyPI, etc is much better than npm's when there are common problems. There's an element of suffering from success but some of the problems have been around in RubyGems and PyPI before Node/npm took off and those were seen as the hot technologies.

Re: Finding relationships between Ruby’s top packages and their dependencies

#15
post #7
post #3

Aside from Shopify and others from that era, what modern SaaS offerings are choosing Rails (or Ruby) for their main app? I had one last peer still using Rails, and since Heroku's been on the ropes they're out. Other than DHH adherents, is anybody still excited about Rails? To draw an even smaller circle, is anybody still excited about Ruby when Rails isn't involved?

I'm pivoting my career away from Rails after 10 years with it. Elixir and Phoenix fills the Rails void and does what Rails does better than Rails with usually better code at ~7x the speed. In my opinion - there's no reason to build a new app in Rails today aside from familiarity.

FWIW, I started with 2.X back in 2007/2008 and I have decided that my current employer is my last role working in a Rails shop.

Re: Finding relationships between Ruby’s top packages and their dependencies

#16

Earlier quoted context omitted.

As it happens, folks from RubyGems, PyPI, npm and others meet regularly to discuss common problems and share ideas: https://github.com/ossf/wg-securing-software-repos

That's not very surprising. I think what's surprising is the perception of RubyGems, PyPI, etc is much better than npm's when there are common problems. There's an element of suffering from success but some of the problems have been around in RubyGems and PyPI before Node/npm took off and those were seen as the hot technologies.

My experience is that the average npm-based app has significantly more (and smaller) dependencies than a similarly-sized Ruby or Python app, even before factoring in that npm permits using multiple versions of the same dependency at once. This isn't necessarily a bad thing, but it results in a somewhat different set of issues.

Re: Finding relationships between Ruby’s top packages and their dependencies

#17
post #3

Aside from Shopify and others from that era, what modern SaaS offerings are choosing Rails (or Ruby) for their main app? I had one last peer still using Rails, and since Heroku's been on the ropes they're out. Other than DHH adherents, is anybody still excited about Rails? To draw an even smaller circle, is anybody still excited about Ruby when Rails isn't involved?

I would have used Rails for the current project I'm on, but for one thing:

Data science.

In the past (around 2010 to about 2018) I did the web stuff in Rails and communicated through the database for the ML stuff I needed from Python, but even though Rails is better than Django, these days Django is good enough and it isn't worth the tooling and the employee dual lingual requirements to justify both.

It sucks and I wish I could use Ruby more. I agree Ruby and Rails are both better than Python and Django on their own, but the scientific computing part of Python is just so phenomenal that there isn't really anything to do about it anymore other than to accept it.

Ruby is like Elivish. It's poetic and beautiful and consistent where it counts, full of symbolism and grandeur, but in a world of dwarves, humans, and orcs it just isn't useful enough to justify making an entire team learn it.

Re: Finding relationships between Ruby’s top packages and their dependencies

#18
post #3

Aside from Shopify and others from that era, what modern SaaS offerings are choosing Rails (or Ruby) for their main app? I had one last peer still using Rails, and since Heroku's been on the ropes they're out. Other than DHH adherents, is anybody still excited about Rails? To draw an even smaller circle, is anybody still excited about Ruby when Rails isn't involved?

Me. I am. I like Ruby. It’s simple and easy to use.

Re: Finding relationships between Ruby’s top packages and their dependencies

#19

I'm pretty convinced Ruby and Python's package ecosystem has most of the same problems of JavaScript's but it's just not talked about as much. This article definitely has a lot of similarities to npm's MFA implementation and security concerns that have come up.

Not true at all, at least for Ruby.

Most larger React projects have _far more_ dependencies_ than an equivalent Ruby project. You could chalk it up to a few things I think:

* the JS ecosystem is just much larger - more devs (especially inexperienced ones) means more code and more copy/pasting solutions that rely on `npm install` from the web.

* JS has just not been as stable and mature as Ruby or Python until the past couple of years (thanks to ES5/ES6), especially if you consider the browser acceptance of latest ES.

* The general explosion of NPM packages that do dumb, trivial shit - see https://www.npmjs.com/package/is-odd and https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how... for two examples.

* There are at least four major tools to manage dependencies in JS: npm, pnpm, yarn, and yarn 2. This often means you end up with multiple ways teams are handling JS deps in their projects, with all the non-essential complexity that comes with it. In Ruby there is just one way - Bundler. I don't even want to talk about python.

* There are more leading frameworks to choose from in JS, which means you have libraries that support all of them, doing things in slightly different ways. Consider a legacy Angular app that updated to React in 2018 and is updating to Svelte or whatever now. If the team hasn't been very disciplined in updating and removing all transitive dependencies through the upgrades, you will inevitably end up with a ton of stuff (is `react-date-wrangler-jobber` used? I still see references to it, but is that page live? who knows!?) in your bundle hanging around and cluttering up your build.

I've been updating things across our main React/Rails product at $current_job. Most major dependencies were out of date by 1-2 years. Updating Ruby has been *so much* easier, whereas the React / npm stuff often ends up in a rats nest of conflicting dependencies. And this is after we made a major effort in our build and packaging setup across the board.

I do think it is getting better in the npm world, slowly. Ever so slowly.

Re: Finding relationships between Ruby’s top packages and their dependencies

#20

I'm pretty convinced Ruby and Python's package ecosystem has most of the same problems of JavaScript's but it's just not talked about as much. This article definitely has a lot of similarities to npm's MFA implementation and security concerns that have come up.

I'd suggest there's a correlation between the size of those package repositories and how much they get talked about. npm has several times the package count of PyPI and RubyGems together, and I don't think that can be accounted for just because it's common to make "micro" JavaScript packages.
Post reply on HN