1. 36

Ranty (a little bit) essay on problems of Ruby ecosystem. Quite a few examples of code that might cause you a headache, as well as some examples of good Ruby libs.

  1.  

  2. 14

    The culture that sprung up around Rails is the problem.

    I can’t stand to use Rails because I always feel like I’m playing in DHH’s sandbox. When using Rails, it’s much less Ruby and much more Rails. There’s a vast, beautiful ocean of computation out there, but Rails presents it as a little puddle in the sandbox. A commoditized architecture, by definition, can only be mediocre at best.

    I no longer believe more and more metaprogramming can solve the Software Problem. Application devs respond by learning less/caring less to fill in the gap covered by this. Anything that requires more rigor on their part is rejected by the mainstream, ensuring that software quality will not increase over time. I still believe in tools, but I believe developers have to care/practice in order to write good code.

    1. 6

      Even if you’re only using Ruby, it’s more Rails than Ruby, at least when searching for documentation. “How do I do X?” (e.g. title case a string) always results in an answer “just do Y” (“foo”.titlecase) that only works if you’ve included at least some of the rails gems. Try to find out which gem? It changes every week, but nobody seems to care since everybody just uses the whole thing.

      1. 1

        I have no comment on the specific example of title casing, but I have found the Ruby language documentation in general to be excellent, and I have not had issues find non-gem solutions to my google queries.

        The Rails community does rely on many external libraries (although I hardly think more than the Java ecosystem for example), but then the primary use case of Rails is rapid prototyping. I will concede that I have seen wastefully added gems, but I will equally say that if your goal is to get a startup MVP into production, maybe writing an authentication framework is not the best use of your time (use devise for example).

        There are a lot of problems with Rails, and I am by no means a fan of the DHH style the project has taken. But having used Rails for the better part of 5 years now, I think that these criticisms are excessive, miss the mark, and are not reflective of a mature/experienced Rails dev. Any responsible engineer evaluates the code quality, test coverage and current maintenance (at a minimum) of any library she brings into a project, and the fact that some engineers fail to do their due diligence is in no way unique or even over-represented in Rails.

        1. 4

          Your comment seems an inadvertent confirmation of the problem I’m talking about. I wasn’t using rails (nor did I want to, since I wasn’t building a web app), but most of your comment is explaining the merits of rails.

          1. 1

            Apologies :) I realize I was responding at least in part to the comment below yours, which is unfair to you and inaccurate.

      2. 5

        The Rails (not ruby!) community always feels a bit “iphone hipster” to me: there’s a gem for that!

        Your skills as a Rails developer are measured in how many Gems you know/can use in a single app.

        1. 4

          I’m not a huge Rails fan (I was involved in another Framework), but - isn’t that a good thing? It means code reuse is there, possible and happens. There’s an active “commons”.

          1. 2

            Sure, untill all you do is combine gems: and hit a brick wall when you have to “innovate”. I’ve seen it happen unfortunately…

            1. 3

              Yes, but “some people build stuff on their own and some just assemble” doesn’t strike me as particularly new or rooted to the Rails community. All these gems come from somewhere…

              1. 2

                True, it’s just a general tendency i notice @work. The same “culture” is - imho - also present in Javascript land. I don’t see it as fully negative; just as you outlined it actually. Perhaps a better wording would be: I see our “juniors” hit walls really hard because they never “learned to do it themselves”.

              2. 3

                The groupthink around open source is enormous: “open source everything except your core business!!!” OSS is not a guarantee of quality. Actually, I’m petrified of future programming ventures being overrun by this simplistic, collectivist mindset, whereby devs are mostly integrating all the ‘best-practice’ OSS libs decided by the ‘community’ (read: self-promoting hegemony).

                Additionally, I believe OSS is ultimately a bad vehicle for R&D; mostly because it’s expensive. The result of R&D is often open source (React), but OSS tends to imitate over innovate. Additionally, innovative OSS often faces adoption hurdles: get too far ahead of the crowd, and network effects ensure that few will try to understand your library, mostly because no one else has.

                1. 3

                  I think there is a perception mismatch between those who want to advance things and those who “just build”.

                  My first job was at a company where the core business was selling websites to pharmacies.[1] Some static pages, a module for adding news, a module for calendering if they planned events. Other then that, they had really good, css-editable templates to make every site look personal in 1-2 hours. They didn’t have much technical experience there, but they were providing a lot of value. They were just sourcing the commons and thus enable small business to have affordable web services. It took me a year to understand that and not be frustrated there, because I wanted to build new stuff.[2]

                  Open-source moves the bar of what can be implemented just by sourcing the commons every year. People that “just” assemble gems are experts in that: providing off-the-shelf products using that. That’s the collective group that we see. A lot of busy people that provide services in short timeframes. They do pagination using will_paginate because it costs 15 minutes instead of an hour. That’s great. It’s just not a model for the next soundcloud.

                  That’s why I think all this is great and the success is well-deserved. The only thing I still see lacking is a good navigator for the commons.

              3. [Comment removed by author]

                1. 5

                  I’d like to have proof of that. Just throwing around the assumption (that the parent didn’t express) doesn’t advance the discussion in any meaningful way.

                  Maybe that is what sets a good Rails developer apart from a bad one? E.g. Discourse has a huge list of dependencies and I wouldn’t call it a low-quality product. When we take, for example, the PHP community, the argument is often turned around: too many people implement the same stuff over and over again, poorly. It doesn’t hold back the community from having quite a list of high-quality products.

                  It’s one of those nice statements you can have in both ways and use them as you personally find appropriate. Please substantiate your claims.

                  I’d go a step further and say that there is no community that has solved the “many small libraries and lack of visibility” problem.

          2. 11

            Although Ruby (on Rails) is my bread-and-butter… I can’t but agree with this article. It’s also one of the reasons I’m “sneaking” in Go @work: It requires less discipline.

            There’s nothing wrong with discipline; it’s just too easy to slip up.

            1. 7

              At some point you should work with your tools, or switch tools. If everything expects to be configured by environment variables… maybe set the damn environment variables. Is using code rather than envvars really the hill you want to die on?

              The author claims this isn’t about dynamic languages in general, but as far as I can see everything still applies - maybe Python doesn’t have quite the same monkeypatch culture that Ruby does, but there are frameworks that do that and they will interact in surprising ways and cause bugs. Fundamentally, dynamic languages make programs easier to write but harder to maintain, because as the author says everything becomes dependent on discipline. And there’s no way to retrofit a type system onto an existing language and have it turn out nice, so you’re stuck with rewriting - I know I worked on one team that claimed to be “rewriting our PHP in Java for performance”, but really performance was less of an issue than maintainability.

              For me, Ruby is not making it easier for me to produce high quality software. This is extremely important to me personally and professionally. I see every uncaught error or incorrect business logic implementation as fundamental failure on my part. I don’t expect to write bug free code, but I do expect to eliminate of 100% of certain classes of errors.

              If you feel that way then you shouldn’t be using Ruby, period; you should be writing something like Idris, or at least Haskell (maybe F# or Scala if you’re subject to platform constraints). But I question whether that’s a productive way of thinking. Programmers angst a lot about high quality software, but from a business perspective high quality is often much less important than implementing functionality fast.

              Every programmer realises, in practice if not in theory, that a certain defect rate is acceptable. But we seem fundamentally unwilling to admit that publicly, which leads to stunted discussion as everyone tiptoes around the real advantages of certain approaches. Functional language marketing emphasises greater safely, but hardly anyone is limited by the available safety in their language - very few people code at the minimum defect rate possible in their language. Rather, most people already code at the defect rate that’s acceptable to their business - so the real advantage of switching to a functional language is to write much less test code while maintaining the same defect rate.

              1. 4

                Recently I’ve been lucky enough to avoid HTTP+JSON for the majority of my work. This has been great because there’s been no bullshit for me to worry about. No frameworks, no bloated libraries. Just straight up Ruby and essentially just concord and thrift in the Gemfile.

                I’ve been working almost exclusively in Rails the last three years, doing string plumbing schlepping things in and out of various databases and markup languages. My list of preferred Ruby tools looks much the same as his: I’d add adamantium, equalizer, and maybe attestor (a nice idea that needs to not use exceptions for control flow). I have a hard time recommending FactoryGirl because I’ve seen it help teams accrue ever more technical debt once they’ve passed the point that they can’t even instantiate model objects in a unit test in a couple lines of code. Lotus and ROM are young but have some real potential.

                I wonder if Rails would already have succumbed to sclerosis if it hadn’t been for merb, a competing web framework with a much nicer internal design that merged into Rails. Rails 3 looks a lot more like merb than it does Rails 2, it feels like Apple’s acquisition of NeXT where the little fish ate the big one. Maybe there’s the possibility of doing that again, though the Rails community has been really dismissive of efforts like Trailblazer to improve on the default MVC ball of mud.

                It’s really encouraging to see folks like Adam Hawkins, Markus Schirp, and Piotr Solnica thinking along the same lines, though even as I’m preparing a RailsConf talk on this topic I wonder if it’s worth trying to make a little movement in Ruby or decamp to another toolchain.

                1. 9

                  There’s a Ruby minimalist counter-culture brewing, and I’m aware of companies hiring developers to work on projects with Cuba, a tiny microframework. I have lots of projects built with Cuba, Ohm, Shield, Mote, Scrivener, and many other small Ruby libraries that get the job done. I recently wrote a comment about small libraries in /r/ruby, I hope you find it interesting. I know many other developers who are in a similar search for lean software, and there’s definitely a way to build applications with simplicity in mind.

                  1. 4

                    I’m mostly a bystander here, but I did have hopes, years ago, that the Merb merge would punt Rails in a less monolithic direction. I don’t use Rails, but it’s undeniably influential, and I want it to help developers be productive, both directly and by influence.

                    These hopes were pretty much dashed by later “features” like Turbolinks, which even Yehuda Katz, if I recall correctly, opposed enabling by default. There has been no move away from Active Record / Support. Rails didn’t internalize the lessons of Merb; it just ate it up and spit out its bones. I wish I could see it differently.

                    Keep fighting the good fight!

                    1. 4

                      Rails is actually quite modular, even if it is not shipped like that. The problem of Rails is that it start with full stack and you need to remove to go lean, while other frameworks like Padrino encourage you to add on a lean basic stack.

                      I am under the impression that removing parts from a system competently is a lot harder then adding to a lean system. The first requires understanding upfront, the second requires you to understand during the task.

                  2. 2

                    Summary:

                    • Good libraries shouldn’t modify or depend on global state.
                      • Libraries should not read configuration from global state, such as environment variables or files in certain places, but rather should be configured in code. This makes deployment of client code easier.
                      • Libraries should not monkey-patch by default. Monkey-patches are hard to debug when the patched method is doing something you don’t want, but you don’t know where or how to disable that.
                    • Many Ruby libraries do not follow the above principles. The author despairs that the Ruby culture ignores these rules, and so it is hard to find good, safe libraries.
                    • You should use libraries that depend on as few libraries of their own as possible, to reduce the likelihood that any library will have problematic interactions with global state.
                      • The author lists some libraries he has used that he trusts to follow the above principles.