Sick of Ruby, dynamic typing, side effects, and object-orientation (2014)

I switched from Ruby (after ~8 years) to JavaScript at the beginning of this year, and Ruby is a dream in comparison:<p>- Thanks to the proliferation of Rails and similar frameworks, most Ruby apps at least have something that resembles an MVC structure. With JavaScript, once you move past the basic TodoMVC examples you are pretty much on your own. It gives you enough rope to hang yourself, all you colleagues, and everyone in the building next door.<p>- The expect vs should change in RSpec is nothing compared to how fast things are changing in JavaScript. I think there are now 7 different ways of just defining a module.<p>- The stdlib of Ruby is pretty sensible. JavaScript has many inconsistencies (take Array.slice vs Array.splice - one modifies the original array, and the other does not), and you usually need to rely on third party libraries, or write the code yourself, to do pretty basic operations.<p>- The JavaScript community seems to have the opposite of NIH syndrome, so that even basic functionality is offloaded to a third-party modules (see leftpad). The project I&#x27;m working on has over 1000 modules in it&#x27;s dependency tree.

&gt; The majority of my job consists of maintaining about a dozen legacy Rails 2 &#x2F; Ruby 1.8.7 applications, written between 2008-2010, [...]<p>I would be sick of that, too.<p>I&#x27;m also sick of criticism on Ruby when you actually want to criticize Rails. There is a significant overlap in the two communities of course, but both have a distinct profile and you can&#x27;t just lump them together.<p>In this case, it&#x27;s also not helping that they have to stay on an ancient Rails version. With Rails, it&#x27;s a much smoother experience if you can follow the major releases but especially the upgrade to Rails 3 was a painful one.<p>Edit: I don&#x27;t want to imply that you shouldn&#x27;t criticize Ruby but if you do, don&#x27;t confuse issues of Rails with those of Ruby. Rails and Ruby code do have quite a different feel to them. It goes this far that when I write a clever little Ruby snippet in a Rails app, I almost feel dirty as it doesn&#x27;t belong in there.

If these programmers spent half as much time coding as they did bitching about their and others&#x27; programming environments, I think they&#x27;d get a lot more work done. Not to mention, be happier with life.<p>Honestly, I think part of maturing into a senior software engineer (and later, a <i>good</i> manager) is accepting that while things aren&#x27;t perfect, they&#x27;re plenty good enough to solve your problems and make money.<p>I&#x27;m not saying there aren&#x27;t occasionally valid complaints, and sometimes these new tools (Docker, et al) <i>are</i> really good, but the sorts of developers I&#x27;m describing here always think the grass is greener when it&#x27;s programmed in another language. No, of course they aren&#x27;t factoring in the months it takes to convert over for a 1% productivity &quot;boost&quot;. All this grumbling does is hasten your language and tools dropping out of fashion and never improving.<p>If you want things to get better, contribute to your language and its tooling. If you don&#x27;t, just switch out and use something else. Can we skip the swan song each time you decide something isn&#x27;t good enough for you?

It’s a shame that people feel this way about Ruby. The thing about ruby and scripting languages like JavaScript is their nature make them very easy to dig in. That’s why you see these scripting languages being used everywhere. The same problems mentioned here plagues JavaScript yet it’s the most used language on the web.<p>I’ve personally built rails app that have been running for the last 5 years with clients using it to process millions of USD and I rarely have to touch it. And even now when I have to make changes it’s easy to fix and patch up because it was built right.<p>Most founders who don’t understand development “need things done yesterday”. If your business doesn’t take into account technical debt you are going to skimp on things and cut corners. It’s not ruby’s fault. It’s the business owners job to understand development and the process of building risilient long lasting software and not put developers into impossible timeframes.<p>From my experience business and marketing people who “need it now” don’t know what they are doing business wise too. Businesses take years to build. Nothing is ever needed “right now” if business is well planned and well executed. There is always enough time, and if there really isn’t technical debt is accounted for and fixed quickly.<p>That said it’s also important that technical leadership constantly inform and communicate with business end regarding development time and the concept of technical debt.<p>Don’t even get me started on business people who “need it now” based on “projections”, and then forget about everything they asked for the next day. Or “I need it now” “make it happen” to stroke their ego.<p>When you find yourself blaming the tool look at yourself as an individual and look at your team.

I don&#x27;t really see how this would be much more different from language to language. The being &#x27;sick of&#x27; part, not so much the specific irritations. Every languages has its issues and from all the languages I have tried I have found Ruby to be the most pleasant to work with, but I am sure this is different from person to person.<p>One of the struggles that the writer seems to have is that programming applications is not science, but he seems to think it is. DHH has a great keynote on this phenomenon: &quot;Writing Software by David Heinemeier Hansson&quot;<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=9LfmrkyP81M" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=9LfmrkyP81M</a><p>As mentioned in the comments of the article you will run into issues with any programming language. One of the tricks is to not hold on so tightly to &#x27;rules&#x27;. Like (take from the article) &#x27;break functionality into lots of small objects&#x27;. This is horrible advice if applied to all situations. You should only do this when it makes sense. I see so many programmers breaking up everything in useless classes and methods&#x2F;functions&#x2F;whatever just because someone wrote a blog post about doing so. This just makes complicated code look simple at a glance, but when you want to find out what the code really does you have to jump up and down through files looking at what each function does, you have to open split screens between abstract classes that have some dedicated piece of code in a class that had to exist in order to satisfy the &#x27;break things up&#x27; rule, etc.<p>Long story short: just relax, write code (in whatever language you like, for whatever reason), go home and enjoy your family, friends and hobbies.

I&#x27;ve a love&#x2F;hate relation with Ruby because I think the language itself, is one of the best incarnations of modern very high level programming: the way OOP, imperative, functional primitives are put together is great. On the other side I don&#x27;t like the programming culture that the Ruby community formed, which is on the average not super focused on stability, quality, documentation, essentiality, simple code. At the same time, coming from the Tcl interpreter, I was also not super happy in the past with the Ruby C implementation: once I rewrote certain long running tasks from Tcl to Ruby, memory usage exploded, performances were no longer deterministic, regardless of the fact that the two languages were more or less at a similar level of abstraction and speed. So I love you Ruby, but it&#x27;s hard to use you.

Ruby is &quot;too magical&quot; for its own sake. And then people abuse their right to use it, things like overriding class methods, etc (the syntax doesn&#x27;t help in the least and it has some weird quirks when compared to python)<p>I&#x27;d take a smoke test and some high-level functionality test before the over-testing preached by the TDD &quot;gurus&quot; or any crap spouted by uncle bob. 100% code coverage is a myth, your code still can fail spectacularly with a good code coverage and guess what, most of the software in production today was not TDD&#x27;d let alone unit tested.<p>People sell TDD like a OCD inducing religion instead of something that might be a good idea in some specific cases

(2014 btw)<p>This is all true about Ruby: the things that make it feel so powerful come at a big cost. But of course what the best solution is depends on what you are trying to achieve.<p>I&#x27;m curious if the author pursued learning Haskell and what he thinks of it now. Side effects are inevitable in any non-trivial application that interacts with the real world. They may only happen outside the runtime, but Haskell&#x27;s design makes allowances for the perfection of its type system when it comes to interacting with other systems. Ultimately, the extent and impact of side effects have everything to do with the design of the program, and your compiler won&#x27;t save a poor design. The true test of the design is years of real use and evolution and maintenance, and so I&#x27;d love to hear from people maintaining a huge years-old Haskell codebase how it compares to other languages.

Very weird doing a lot of JS work after Ruby - I feel the same about Javascript, ES6, ES6++, or Typescript. All the code bases I inherit appear to be verbose, useless cruft just to overcome some limitation or to achieve some useless pattern.

While I do echo some of the sentiments of the author, I still LOVE Ruby. I use it for small scale projects, for very quick data processing needs or on Jupyter notebooks. I used to run a full fledged Ruby shop a year or two ago and I have to tell you, in this day and age, even today, there is NO full-fledged equivalent to Rails.<p>Having said that, now I predominantly use Phoenix&#x2F;Elixir for most new projects. And the framework is moving ahead blazing fast. It has its own pros and cons, but overall, it&#x27;s been a VERY positive experience and it actually saves me a LOT of time because I&#x27;m able to find code errors at compile time.<p>It&#x27;s almost the only alternative to Rails which seems like home if you&#x27;re transitioning, but it still has its own issues. For example, they screwed up the code organization with contexts, renamed the web folder a couple of times and so on. But these are small issues and I&#x27;m amazed at the productivity I gained by using Phoenix.<p>I wrote a full fledged Stripe API library in under 12 hours. Well tested and rock solid. Pattern matching is heaven and in many ways, your code is more robust. I have written libraries in Ruby too, they take more time simply because there are lot more tests that need to be written.<p>I would never go as far as saying &quot;I&#x27;m sick of Ruby&quot;, simply because it&#x27;s still a great programming language, if you&#x27;re getting started and also because, I believe in the man behind it - Matz. He has a philosophy and believes in it. It takes enormous passion and dedication to believe in what you&#x27;ve created, support it over decade(s) and keep on improving it. I can point you many languages that have died over the years because they lacked this passion and dedication.<p>Same thing goes for DHH as well. I really applaud him for patiently tolerating so many people bashing the framework he helped to create that revolutionized web development. He&#x27;s also very very chill and respectful about others&#x27; opinions. [1]<p>Having said all this, I hope Ruby 3.0 has a strong come back which is much needed at the moment.<p>[1] <a href="https:&#x2F;&#x2F;www.quora.com&#x2F;What-do-you-think-of-Elixir-and-Phoenix-in-comparison-to-Ruby-and-Rails-Do-you-think-it-is-possible-and-even-recommendable-that-a-lot-of-Ruby-Rails-devs-move-towards-Elixir-Phoenix-in-2017&#x2F;answer&#x2F;David-Heinemeier-Hansson" rel="nofollow">https:&#x2F;&#x2F;www.quora.com&#x2F;What-do-you-think-of-Elixir-and-Phoeni...</a>

Everyone who has used Ruby for some time (at least one full project) will have different bad memories, as well as probably some very happy memories.<p>Few would dispute that Ruby is a great language for getting things done with small, expressive code. And Rails, which is what probably brought most of us to Ruby, was at its time the ideal web framework. It was able to be generations ahead of most other frameworks because of the capabilities Ruby afforded it.<p>However, time moves on, versions of the language, framework, and gems change. Projects grow and evolve. These are where the pains really begin. But this is not really so much about the language but about real world project lifecycles.<p>For me, the first real pain was performance. At some point, you cross a threshold where the performance goes from reasonably ok to WTF is happening?. Then you start profiling and discover that the wonderful collection and ORM operations you&#x27;ve been doing are extremely expensive. That&#x27;s when it stops being fun.<p>Then, if you explore other languages, you may discover the absolute joy of Clojure (once you devote the time to think functional and appreciate Lispy syntax). Plus you get a big performance boost (as well as access to tons of Java libraries that are usually very performant). But alas, then you discover that there&#x27;s no real Rails equivalent for Clojure. (I now understand that there are great options if you&#x27;re willing to cobble your own together.)<p>Finally, you might hear of Elixir + Phoenix. Suddenly (again, if you&#x27;re willing to learn and think functionally), you find joy. Performance is much better than Ruby, the Phoenix framework feels Railsy, and you get the benefit of the industrial Erlang VM underneath it. The downside, however, is that Elixir and Phoenix are young. Fortunately the community is friendly and helpful.<p>For me, it&#x27;s not that Ruby is bad; it&#x27;s just that I now realize how much better functional programming is for me personally. And when I just need something quick and dirty, Python is already installed. Ruby is like an ex-girl(or boy)friend that you still like, but who no longer fits into your life.

my sense is that ruby has a perl problem. yes, you can write very beautiful things in it, and if you follow the idioms you&#x27;re generally safe. but there&#x27;s way too much rope to hang yourself with, too much &quot;magic&quot;, and no way to reliably refactor large codebases. As a language, it doesn&#x27;t scale well into &quot;programming in the large&quot; unless you really know what you&#x27;re doing, and most frankly don&#x27;t.

I have a similar experience with Groovy, the &quot;Ruby of Java&quot;.<p>I wanted to quickly prototype an app, so I used Groovy. It was very productive, esp since I deal with lots of JSON. Over the time, the prototype has grown to be a serious app, and boy I hate refactoring it. Stupid mistakes such as method renaming can be a nightmare. Yes I should have written more unit tests, but my excuse was it&#x27;s just a prototype.

&gt;&gt; The majority of my job consists of maintaining about a dozen legacy Rails 2 &#x2F; Ruby 1.8.7 applications, written between 2008-2010, with essentially zero tests amongst them (when I started).<p>One can write unmaintainable code in any given language&#x2F;framework. I am not a fan of OO but in this case I would not blame OO but the one who developed this messy app.

Beware the enthusiasm of the recently converted.

Ruby: the only problem i have with Ruby is that it is too easy to make a mess. and i do hate rspec with a passion. it&#x27;s a perfect example of a DSL done wrong. otherwise Ruby&#x27;s one of the most enjoyable language i&#x27;ve worked with.<p>dynamic typing: old debate and author contributed nothing to it.<p>side effects: with enough effort and discipline ruby can be very much functional and side effects are less of an annoyance.<p>oop: yeah, but more specifically &quot;what oop has become in past 30 years&quot;.

Most ruby apps have always been a complete pain to setup.<p>The idea of having a build environment and language specific package managers for deploy and pulling in hundreds of dependencies directly leads to dependency hell, a user-hostile setup process and inevitably limits the language and apps to saas type use cases.<p>The only major end user focused ruby apps left are what, discourse, redmine, jekyll? Discourse probably recognizes the complexity of their setup process and has a docker only install which just hides and postpones the complexity, Redmine tries to be available via distribution package managers and user frustration with updating Jekyll is well known.<p>The people who benefit from this kind of adhoc ecosystem of hundreds of small packages, package managers, anything goes are the completely self interested jockeying for influence and move on to the next new thing, the language is left with the debt and its entirely the fault of the language developers.<p>The same thing exists in Node and has now been adopted by the PHP ecosystem taking away the easy setup benefits of PHP.

There&#x27;s dynamic typing, but then there&#x27;s also all the extra stuff like mutable global state, gratuitous monkey patching, fad following, overindulgence in complicated implementation cleverness just to make interfaces more elegant etc etc that the Ruby&#x2F;Rails community has produced and promoted.

I see the &quot;you need to write less tests because static typing&quot; statement thrown around a lot (including the article), but haven&#x27;t seen any detailed discussion on why that would be so, could someone point me to a more in-depth look at that?

I perused the author&#x27;s blog and peeked at his LinkedIn profile. It looks like he continues to do Ruby development, and still calls himself a &quot;Ruby on Rails Developer.&quot; I wonder what caused him to change his mind?

This isn&#x27;t really about Ruby. It&#x27;s about the other things in the title. I suppose that calling out Ruby by name was necessary to make this blog post concrete, and to make it easier to relate to. The author also mentions Haskell, but that really isn&#x27;t necessary to get the point across. The comparison could have been between Python (written in an OO fashion) and ML.<p>You can write, &#x27;I hate X because of dynamic typing, side effects, and object-oriented programming&#x27; for many values of X. Similarly, the reasons why the author is drawn to Haskell can be applied to a large number of other languages.

&gt; I mean, would you be comfortable if your bank relied on software that behaved like this? If not, then why are you even using it for anything else<p>Because not everything I do impacts on the finances of a million people?

Most problems with Rails:<p>- Fat models (huge number of hooks, scopes, many methods stuffed inside in the name of &quot;domain-driven design&quot;, etc)<p>- Fat controllers (huge number of shared methods, hooks, shared variables and hooks, concerns, etc)<p>- Fat views&#x2F;helpers&#x2F;templates<p>In multiple years of working with Ruby (+&#x2F;- Rails) - there is one talk that changed my whole mind of scaling systems - aka ways to build the majestic monolith [1]. And I believe the author of that talk would be laughing silently at this post right now, thinking, &quot;I know what you&#x27;re talking about&quot;.<p>Models, Models, Everywhere by Chris Griego: <a href="https:&#x2F;&#x2F;speakerdeck.com&#x2F;u&#x2F;cgriego&#x2F;p&#x2F;models-models-every-where" rel="nofollow">https:&#x2F;&#x2F;speakerdeck.com&#x2F;u&#x2F;cgriego&#x2F;p&#x2F;models-models-every-wher...</a><p>Check out those slides, and check the codebase. This is not a Ruby problem. Splitting things mindlessly into microservices, trying to go &quot;fully functional&quot; (answer: nope, nothing in the world is pure or perfect), everything has trade-offs.<p>[1] Majestic Monolith: <a href="https:&#x2F;&#x2F;m.signalvnoise.com&#x2F;the-majestic-monolith-29166d022228?gi=f03ff2ca413e" rel="nofollow">https:&#x2F;&#x2F;m.signalvnoise.com&#x2F;the-majestic-monolith-29166d02222...</a>

I&#x27;ve actually moved from ruby too (although, still doing some for contract work), but I wouldn&#x27;t say the language is the problem, nor rails. I was more tired of the community, actually (not the opensource community, but the coworkers).<p>Ruby and rails were awesome in the late 2000&#x27;, when most people were trying to get their essence and do crazy and smart things with them, always focusing on making things easier for the (dev) user.<p>But then, soon after the start of the 2010&#x27;, it started to get really ubiquitous, and there were a lot of people using it who weren&#x27;t especially passionate about development. They started to make everything complicated, not bothering about trying to make things easier, and kept talking about &quot;good practices&quot;, following them blindly without having any clue what problems they were supposed to solve.<p>This is probably something that occurs naturally for any successful tool. I&#x27;m not even blaming those people. And it seems quite normal to me that after spending years among passionate only people doing cool things, we feel bored when things normalize. Time to find an other community, no hard feelings.

After 10 years of the same article over and over again I&#x27;m so bored. Or sick.

I feel like Ruby’s sweet spot is sort of as a cleaner, more capable, more ergonomic Perl, with nice message-passing OO and a super-convenient standard library. Text processing? You bet! Command-line utilities, test harnesses for JVM-hosted APIs (using JRuby), small network services, ... in those domains I feel very productive with Ruby.<p>But for core business logic? Definitely not my first choice.

Never used Ruby really, apart from some Rails programming here and there, but I completely agree: dynamic typing + side effect + OO patterns =&gt; technical debt.<p>On the other hand I think pure languages, like Haskell, take it too far.<p>My ideal language would be something like Haskell + limited side effect support(for IO) + ecosystem of something like Python or Java or Golang.

missing in title: [2014]. Though I&#x27;ve heard the same things a lot longer than that anyway :)

I switched from Ruby to Go and could hardly be any happier. Go feels powerful and simple at the same time. I code whatever i need to code easily, instead of hunting for frameworks and evaluating dependencies (or dreading the next deployment when a dependency changes unexpectedly). The code is easy to read and maintainable due to the lack of multiple layers of abstractions and inheritances. It&#x27;s refreshing.

s&#x2F;Ruby&#x2F;Rails&#x2F;g in the article and it makes more sense. You can write pretty good Ruby code, which avoids side-effects, monkey-patches and is easy to test. All you need to do is abandon Rails. There are many modern Ruby projects which make it simpler, see dry-rb.org, rom-rb.org, hanamirb.org and trailblazer.to

Ruby is a not a great language but my main complaints are:<p>1. installing rvm breaks sometimes due to random code changes (i think the maintainers fix them recently)<p>2. they seem to think every app has just 1 database so they dont support db sharding themselves without a third party gem.<p>3. Net::Http is probably the most unintuitive api for crawling web pages.

I&#x27;m old enough to remember sick of static typing, pointless indirection and mixed paradigm code.<p>And thus the centralisation&#x2F;decentralisation wheel turns again because the new generation think they have discovered something new but ignore the lessons learned in the past.<p>If only we could fix that human tendency with a code upgrade.

... from 2014

In all fairness, this applies to any dynamic language - Especially scripting ones. Python, Ruby, PHP... It doesn&#x27;t matter really, it&#x27;s so easy for a project to grow out of control. I have growing insecurities when I program in these languages.

On a sort of similar note, I&#x27;ve been teetering between Python and Go. On one hand, clearly you can move faster in Python. On the other hand, Go is faster and I can be more sure that code that compiles and passes tests actually works.

This is part of the reason Go is gaining so much popularity. It gives you back all the power and speed of typed, compiled language but without all the tedious parts of C like managing memory and complicated threading.

Now that .Net is cross platform, I&#x27;ve been switching everything over to C#. Besides the fact that it&#x27;s compiled, Visual Studio is a dream to work with.

This needs 2014 in the title. Can someone update?

My experience with switching from static to dynamic or dynamic to static typing is that it I&#x27;ve always missed the other at times. The flexibility of dynamic languages is especially nice when your requirements change a lot, which is a huge problem with what I&#x27;m doing now. I probably prefer static generally, but I&#x27;m glad I&#x27;m primarily working with a dynamic language at the moment.

As a clojure user, I think that testing is easy, even race condition goes trivial with clojure +datomic.

If you can’t be successful writing ruby...I don’t know what to say. I’m a manager&#x2F;exec at a medium sized public company. Recently, I got to code in ruby again after a long time. It was great. It’s still my favorite language. I try to quit it, leave it for another newer, sexier language, but I just can’t. Maybe crystal, but then you can have both!

Ruby makes it really easy to write code at the cost of making it much harder to maintain.q

You are right.

&quot;There are two kind of programming languages: the ones everybody hates and the ones nobody use.&quot;

2014

2014!

Ruby-style monkey-patching just seems like an awful idea. I cringe when I see it used in JavaScript, though it is less and less often seen in the wild now that browsers are less terrible and we tend to use babel and other transpilers instead of having to shim and polyfill around the more broken parts of the language.

It’s a lot easier if you cut it out with the types everywhere, and just focus on writing functions that return values. Values! Pass around values, not weird bespoke type instances everywhere. If that’s not OO, too bad. Above all, keep it simple.