4 ms·

> People who "just want to get stuff done" choose the library with the most features and then beg for even more since they can't be bothered to write the 3 line

> People who "just want to get stuff done" choose the library with the most features and then beg for even more since they can't be bothered to write the 3 lines of code it would have been to solve it outside the library. I feel this so much. I once had a contract for ruby on rails work. They were experiencing severe performance issues, so bad that they were developing in release mode (server won't detect a file change and reload for you). One day I get tired of it and start digging into it. I don't remember how many gems they were pulling in but it was A LOT. I came across one particular gem which saved 3 lines of code. Seriously. I stayed away from the RoR community after that. I recently picked up a contract for more RoR work (after all these years, lol) and ... it's not nearly as bad but it's not good either. Some communities just do NOT respect the risk that dependencies bring.

sgarland 3y ago
My experience from having worked at a mostly Python shop (and loving Python myself), and working at a Node shop, is that the latter is by far the worst. Python probably has just as many shitty packages as Node, but Python’s stdlib is so vast that you often don’t need to, if you bother to read the docs. Today, I was marveling at a function someone wrote at my work to cast strings to Titlecase. I learned today that JS has no built-in for that. That’s a tiny example, but there are far more.
- spyke112 3y ago
  That’s also just a one line function with template literals in JS, if by Titlecase you mean upper casing the first character. Maybe a bit overkill to bake into a stdlib.
  - charlie0 3y ago
    It's not about ease, it's about frequency of use. If it's used often, it should be in a stdlib.
moritonal 3y ago
Given you've seen the same effect in both Ruby and JS maybe the takeaway should instead be that there is a group of devs who will always reach for a package first, not that a specific language has a problem.
- PH95VuimJjqBqy 3y ago
  and that group of devs tends to flock to certain ecosystems. I've never seen a .net project with 100+ dependencies, I've easily seen that multiple times for RoR and node.
  - majormajor 3y ago
    In Javaland you can have a huge nested tree of dependencies but you often don't have a "Gemfile.lock" or such to list them all in a file in your repo...
    - PH95VuimJjqBqy 3y ago
      I'm not a fan of the Java community either, they love their structure. people jest about the FactoryFactoryFactory but you'll legit see that stuff out in the wild. Paradoxically, I like the PHP community because they're so practical (yes, the language itself is ugly). RoR built rake for running jobs (it does more things, but that was the primary motivation). PHP community just used cron. Although, having said that, Laravel takes a lot of its cues from RoR and has the same sort of tooling. But when Laravel first hit the scene a lot of people would criticize it for its use of static, but it was legitimately nice to use and that won out in the end. I don't make a judgement of Rails as a community. Most of my Ruby work has been Ruby on Rails so that's' the lense I see things through. Rubyists may be the most practical of all, it's just that so much of Ruby code is RoR that it's difficult for me to separate them out.
  - moritonal 3y ago
    Of all the languages I didn't think you'd hold .NET as the pillar of lean dependency trees. Maybe it's bad luck, or even just me, but NuGet hell is a real place I've been to and .NET's packaging system is brutal at resolving when you pass even 50 packages.

sgarland 3y ago

My experience from having worked at a mostly Python shop (and loving Python myself), and working at a Node shop, is that the latter is by far the worst. Python probably has just as many shitty packages as Node, but Python’s stdlib is so vast that you often don’t need to, if you bother to read the docs. Today, I was marveling at a function someone wrote at my work to cast strings to Titlecase. I learned today that JS has no built-in for that. That’s a tiny example, but there are far more.

spyke112 3y ago
That’s also just a one line function with template literals in JS, if by Titlecase you mean upper casing the first character. Maybe a bit overkill to bake into a stdlib.
- charlie0 3y ago
  It's not about ease, it's about frequency of use. If it's used often, it should be in a stdlib.

moritonal 3y ago

Given you've seen the same effect in both Ruby and JS maybe the takeaway should instead be that there is a group of devs who will always reach for a package first, not that a specific language has a problem.

PH95VuimJjqBqy 3y ago
and that group of devs tends to flock to certain ecosystems. I've never seen a .net project with 100+ dependencies, I've easily seen that multiple times for RoR and node.
- majormajor 3y ago
  In Javaland you can have a huge nested tree of dependencies but you often don't have a "Gemfile.lock" or such to list them all in a file in your repo...
  - PH95VuimJjqBqy 3y ago
    I'm not a fan of the Java community either, they love their structure. people jest about the FactoryFactoryFactory but you'll legit see that stuff out in the wild. Paradoxically, I like the PHP community because they're so practical (yes, the language itself is ugly). RoR built rake for running jobs (it does more things, but that was the primary motivation). PHP community just used cron. Although, having said that, Laravel takes a lot of its cues from RoR and has the same sort of tooling. But when Laravel first hit the scene a lot of people would criticize it for its use of static, but it was legitimately nice to use and that won out in the end. I don't make a judgement of Rails as a community. Most of my Ruby work has been Ruby on Rails so that's' the lense I see things through. Rubyists may be the most practical of all, it's just that so much of Ruby code is RoR that it's difficult for me to separate them out.
- moritonal 3y ago
  Of all the languages I didn't think you'd hold .NET as the pillar of lean dependency trees. Maybe it's bad luck, or even just me, but NuGet hell is a real place I've been to and .NET's packaging system is brutal at resolving when you pass even 50 packages.