16 ms·

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

295 points by setra 9y ago

mattbillenstein 9y ago
... from 2014
- tree_of_item 9y ago
  Well, it hasn't gotten any better since then.
antirez 9y ago
I've a love/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'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's hard to use you.
- pjmlp 9y ago
  I think Ruby missed the opportunity to be a more general purpose language beyond Rails projects. Since its early days, I was hopping for it to gain AOT/JIT compilation support, eventually by getting some inspiration from Dylan. RubyMotion seemed to be it, but because it is commercial product, it is largely ignored by the community. The JRuby work is awesome, then again some in the Ruby community suffer from Java allergy and won't touch it. Now we have Crystal as the best way to get a bit of both worlds, AOT and Ruby like syntax, but still alpha quality.
  - look_lookatme 9y ago
    I agree about Crystal, the way it dispenses with metaprogramming in favor of macros is simple and elegant and optional type restrictions gives me most of the control I want.
- matthewmacleod 9y ago
  Indeed, I think I really share this view. Ruby is the only programming language I've ever used where I didn't feel like I was fighting it, or struggling to express what I wanted. It was easy to express complex behaviours and data structures without reams or syntactic or structural noise. But yes – despite that, there was a lot of shoddy and poorly performing code out there. The ecosystem never saw the kind of massive investment that JS (for example) did, so performance was always lacklustre, and I'd particularly love optional typing. Still, there are other options now for specific use-cases, which is good.
Doctor_Fegg 9y ago
> 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 Because not everything I do impacts on the finances of a million people?
diminish 9y ago
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.
- whostolemyhat 9y ago
  What's ES6++?
  - diminish 9y ago
    Javascript after ES6. I don't think we'll see ES7 etc - so I name them ES6++.
mosselman 9y ago
I don't really see how this would be much more different from language to language. The being 'sick of' 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. 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: "Writing Software by David Heinemeier Hansson" https://www.youtube.com/watch?v=9LfmrkyP81M https://www.youtube.com/watch?v=9LfmrkyP81M 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 'rules'. Like (take from the article) 'break functionality into lots of small objects'. 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/functions/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 'break things up' rule, etc. Long story short: just relax, write code (in whatever language you like, for whatever reason), go home and enjoy your family, friends and hobbies.
- StreamBright 9y ago
  True, however some languages have much less 'sick part' than others. It is just unfortunate that we humans tend to pick up the worse of everything. There is some hope though. In recent years there are many projects trying to provide a better programming experience and safer, faster results. Rust, ReasonML for example.
  - mosselman 9y ago
    I have yet to find a better programming experience than Ruby myself, but Rust looks fine for systems programming, etc. I don't understand however why people invest so much effort in Javascript. The amount of tooling around it just baffles me, but again, to each his own.
deleted 9y ago
[deleted]
noncoml 9y ago
Never used Ruby really, apart from some Rails programming here and there, but I completely agree: dynamic typing + side effect + OO patterns => technical debt. On the other hand I think pure languages, like Haskell, take it too far. My ideal language would be something like Haskell + limited side effect support(for IO) + ecosystem of something like Python or Java or Golang.
- tigershark 9y ago
  Basically F#
  - tluyben2 9y ago
    MS still gets a lot of flack, but F# is nice imho (as is F* for the crazies like me by the way) and is getting better and better with the open source, Core etc. But for 'normal' environment, C# also just works a lot better for teams in my experience than something like Ruby. It might be just taste, but I did large projects in both and C# (also F#) make me sleep at night, while somehow the RoR stuff always needed constant attention (lot of breakage after security related gem updates etc). Nice if you have the people and need for that kind of thing, but a lot of what we do is set-and-forget (at least for a few years) which .NET allows generally. The only thing I don't like yet about the .NET dev experience is the lack of tooling, especially on Linux. But that's rapidly getting there, and is open source under a good license for the most part.
    - pjmlp 9y ago
      F# has become a second class citizen on .NET with the team catching up with what the official .NET team (C# and VB.NET) is doing across all supported platforms. Even C++ has more tooling love than what F# currently has. Anyone that wants to be sure their code will run in whatever platform Microsoft might think of supporting next, should not focus too much on it, unless the wind changes again.
    - pythonaut_16 9y ago
      The thing that frustrates me about F# is it seems to be a bit of a frontier language on .NET. Theoretically you can use it anywhere you would use C#, but there's not a ton of examples or documentation out there. Googling ".NET MVC F#" returns an article from 2010 as its top result, for example.
artellectual 9y ago
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. 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. 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. 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. 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. 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. When you find yourself blaming the tool look at yourself as an individual and look at your team.
- gaius 9y ago
  The same problems mentioned here plagues JavaScript yet it’s the most used language on the web. JS achieved popularity because it was the ONLY choice in its domain. That's a rarity in PLs, and can't be extrapolated to any other language that I can think of offhand.
  - artellectual 9y ago
    NodeJS is a choice, not a compulsion like client side. Be sure to make that clear separation.
wiradikusuma 9y ago
I have a similar experience with Groovy, the "Ruby of Java". 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's just a prototype.
- sgift 9y ago
  > Yes I should have written more unit tests, but my excuse was it's just a prototype. Never understood this point "well, you don't need types, you can just write tests for it". IMO you should never have to write tests for something a type system can find for you. Why should I waste time with something which can be found by the compiler?
  - zurn 9y ago
    This is the path to formal methods. You will build formally correct programs very slowly, usually too slowly for the world/app domain.
    - bjz_ 9y ago
      This need not be the case forever. It's still an open problem, but the tooling is getting better all the time! For now types+tests are a happy medium. No need to throw the baby out with the water just because 100% correctness is still unfeasible for everyday business problems.
  - crdoconnor 9y ago
    I find that strict type systems are good for 'locking down' execution space and sanity checking but they're not effective at cleanly specifying higher level verification even when that's possible. I'd rather use a combination of tests and stricter type checking. There's no sense in being a fundamentalist about either approach.
    - 9y ago
raverbashing 9y ago
Ruby is "too magical" for its own sake. And then people abuse their right to use it, things like overriding class methods, etc (the syntax doesn't help in the least and it has some weird quirks when compared to python) I'd take a smoke test and some high-level functionality test before the over-testing preached by the TDD "gurus" 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'd let alone unit tested. People sell TDD like a OCD inducing religion instead of something that might be a good idea in some specific cases
- crdoconnor 9y ago
  >Ruby is "too magical" for its own sake Magic is extremely useful in the right place (e.g. building ORM or admin frameworks) - these can save you from writing a ridiculous amount of code. Unfortunately since it's an 'advanced' feature lots of programmers want to shove it in places where it not only isn't necessary, but is actively harmful. Python has all the same features and allows you to write code that is equally horrible (or powerful), but it benefits from a cultural bias in favor of simplicity. That said, I've still seen unnecessary magic code written by people looking to prove that they are no longer "intermediate developers". >People sell TDD like a OCD inducing religion instead of something that might be a good idea in some specific cases I think TDD with integration testing works in almost all cases, but unit tests fail or work poorly in about 85% of cases. Unfortunately, unit test driven development is what the zealots preach.
  - raverbashing 9y ago
    > Magic is extremely useful in the right place (e.g. building ORM or admin frameworks) - Totally agree. Python does it in a more explicit way, so that you know "Here be Dragons" (in this object, that was defined in that specific place) It's not like a piece of casual code in any module can turn your world upside down.
  - mypalmike 9y ago
    > Python has all the same features and allows you to write code that is equally horrible (or powerful), but it benefits from a cultural bias in favor of simplicity. It's not a cultural bias. It's a critical difference in the language designs. In python, monkeypatching is scoped to a module. In Ruby, monkeypatching is global to the execution environment. So in Python, you can look at the source code for a module in isolation and deterministically reason about what it does. In Ruby, you can't. Because you can't know what the execution environment will be. IMO, it's the main reason why Ruby projects become harder to manage as they grow. Somewhere, someone is monkeypatching, and reasoning about the code becomes harder and less local. I spent 2 years with Ruby and will never use it again if I can help it.
megaman22 9y ago
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.
- hxegon 9y ago
  It's really not as bad as people make it out to be. Really handy when you need it, and there are limiting mechanisms (refinements) for when you don't.
_Codemonkeyism 9y ago
After 10 years of the same article over and over again I'm so bored. Or sick.
cobbzilla 9y ago
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're generally safe. but there's way too much rope to hang yourself with, too much "magic", and no way to reliably refactor large codebases. As a language, it doesn't scale well into "programming in the large" unless you really know what you're doing, and most frankly don't.
lucaspiller 9y ago
I switched from Ruby (after ~8 years) to JavaScript at the beginning of this year, and Ruby is a dream in comparison: - 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. - 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. - 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. - 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'm working on has over 1000 modules in it's dependency tree.
- bryanrasmussen 9y ago
  I guess I have to agree with everything else, but maybe MVC isn't the best model for a JavaScript application.
- dfischer 9y ago
  MVC is a simple concept. You don’t need a framework to organize your modules. You can easily do MVC in Js from a vanilla setup. As another commentor suggested, maybe MVC isn’t the right abstraction for the need. That’s the balance in my experience. Sometimes it makes sense, sometimes not. In the end make the compromise that allows you to develop with high reasoning ability and iterate from there.
  - meesterdude 9y ago
    > Sometimes it makes sense, sometimes not. for at least 90% of the problems out there, its the the best approach. There are a lot of design patterns out there, but you can do a lot with MVC. From what i've seen, the reason developers tend to shy away from it is because it's TOO simple. They don't feel proud of it, because its so cut and dry. They want to create something unique and interesting and challenging, even if a simple solution would do just fine. But it's not a balance, or a 50/50 sort of decision making. Really, MVC should be your first choice, and you better have a really good reason for it to not be, and a really viable alternative.
riffraff 9y ago
missing in title: [2014]. Though I've heard the same things a lot longer than that anyway :)
tomerbd 9y ago
You are right.
neya 9y ago
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. Having said that, now I predominantly use Phoenix/Elixir for most new projects. And the framework is moving ahead blazing fast. It has its own pros and cons, but overall, it's been a VERY positive experience and it actually saves me a LOT of time because I'm able to find code errors at compile time. It's almost the only alternative to Rails which seems like home if you'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'm amazed at the productivity I gained by using Phoenix. 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. I would never go as far as saying "I'm sick of Ruby", simply because it's still a great programming language, if you'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'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. 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's also very very chill and respectful about others' opinions. [1] Having said all this, I hope Ruby 3.0 has a strong come back which is much needed at the moment. [1] https://www.quora.com/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/answer/David-Heinemeier-Hansson https://www.quora.com/What-do-you-think-of-Elixir-and-Phoeni...
- the_angry_angel 9y ago
  > renamed the web folder a couple of times and so on Just to add a bit of information to this, they were all in RC or pre-releases. I was bitten by this myself, but if you choose to run RC code then you need to own that a little bit.
antod 9y ago
There's dynamic typing, but then there'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/Rails community has produced and promoted.
randomsearch 9y ago
Beware the enthusiasm of the recently converted.
- iso-8859-1 9y ago
  But if he had been writing Haskell for 10 years, he would become humble like most Haskellers are, and he would write no blog post at all. :P
  - agumonkey 9y ago
    They're not humble or silent, they just obfuscate insult in unicode antique code points over the category of categories.
- mark_l_watson 9y ago
  I thought the same thing. I have written a ton of Ruby, used to be Rails, now text Processing with occasional Sinatra apps. I also write a reasonable amount of Haskell. There is no way that I am anywhere near as productive in Haskell as Ruby, but I like Haskell and for some things I very much prefer it. I would argue that it is a good thing to use two very different languages.
kristaps 9y ago
I see the "you need to write less tests because static typing" statement thrown around a lot (including the article), but haven't seen any detailed discussion on why that would be so, could someone point me to a more in-depth look at that?
- delta1 9y ago
  I have no links to share, but it seems obvious that a dynamically typed language will need tests to ensure that a function "behaves" correctly given incorrect types, where the statically typed language will not even allow you to run that code.
- bjz_ 9y ago
  Testing attempts to pin down specific use cases to ensure that they meet certain requirements. Alas they only single out one case at a time - there could be a wide range of possible failure conditions you forgot to test. Types allow you to cut down the space of possibilities to a more manageable level to ensure that your testing can be more targeted. To see this pushed to the extreme, and to have a glimpse of the future, check out Edwin Brady's book "Type Driven Development with Idris": https://www.manning.com/books/type-driven-development-with-idris https://www.manning.com/books/type-driven-development-with-i... - I don't expect this style of programming to become the norm until at least another several years, but it essentially allows you to push all behavioral specifications into the types, rendering most unit testing tests obsolete. Of course I would still have smoke and integration tests to for sanity checking sake.
TimTheTinker 9y ago
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. But for core business logic? Definitely not my first choice.
- meesterdude 9y ago
  > But for core business logic? Definitely not my first choice. I have an alternative perspective. It's clarity, refactorability and testing ability make it a great choice for core business logic. In fact, I am yet to see a cleaner alternative. I've seen rails app's go from monolith to Go microservices, and the clarity of whats going on and agility for change is just gone. It becomes a nightmare to work with.
  - TimTheTinker 9y ago
    Interesting... I personally prefer C# for core business logic. OO where you need it, great libraries & interoperability, functional programming support... good stuff. Wish I had time to look into Clojure. Excellent programming paradigm along with the interoperability, libraries, and platform support of the JVM.
sink 9y ago
This isn't really about Ruby. It'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't necessary to get the point across. The comparison could have been between Python (written in an OO fashion) and ML. You can write, 'I hate X because of dynamic typing, side effects, and object-oriented programming' 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.
- lmm 9y ago
  Yes and no. Ruby has a particularly dynamic, side-effecty culture, even more so than Python (where monkeypatching is less encouraged, OO is less of a focus, and, not coincidentally, unit testing is far less a source of fuss and trouble). Haskell goes in for stronger isolation of side effects than OCaml does. Any given language will be at some point on the spectrum, but Ruby and Haskell are probably the extreme ends of that spectrum as far as mainstream languages go.
keymone 9y ago
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's a perfect example of a DSL done wrong. otherwise Ruby's one of the most enjoyable language i've worked with. dynamic typing: old debate and author contributed nothing to it. side effects: with enough effort and discipline ruby can be very much functional and side effects are less of an annoyance. oop: yeah, but more specifically "what oop has become in past 30 years".
- ajnin 9y ago
  > side effects: with enough effort and discipline ruby can be very much functional and side effects are less of an annoyance. Not when importing a module written by someone else, as all non-trivial apps need, can impact your code.
  - keymone 9y ago
    true, but over time you get better at isolating these gems (pun intended).
neilwilson 9y ago
I'm old enough to remember sick of static typing, pointless indirection and mixed paradigm code. And thus the centralisation/decentralisation wheel turns again because the new generation think they have discovered something new but ignore the lessons learned in the past. If only we could fix that human tendency with a code upgrade.
- lmm 9y ago
  No, we really have discovered something better. We oscillate but we are converging: these days all serious statically typed languages have some level of type inference, and all serious dynamically typed languages have some level of optional type checking. We end up overcorrecting each time - Ruby was an overly dynamic, unmaintainable response to the strictness of Java, and no doubt some post-Ruby languages go too far in the straitjacket direction - but at the same time languages on both sides are better than they were previously.
  - neilwilson 9y ago
    Ruby has optional type checking. What do you think the testing regime is about? It's a compiler that is built for each project with types specific to the domain problem being solved. Language type checking misses the point. The types I want to check, and the extent I want to check them, are in the spec files. Go type inference, for example, is deeply primitive and an awful lot of Go code seems to spend its time implementing duck typing via work arounds. It looks an awful lot like dependency injection for the 2010s.
    - bjz_ 9y ago
      Go is a terrible example of a statically typed language. Now that is an example of a bunch of people not learning from the past - ie. the entire lineage of ML-based languages! A rich type system lets you mold and shape the types to fit nicely over your domain, effectively becoming a machine-verified DSL for your business problem. It will catch flaws in your mental model before you even begin to write tests or an implementation, and is a cheap way of sketching out your ideas and great documentation to have over the lifetime of your project. Of course you can't fit it exactly, so you need a smattering of spec tests, and probably some property-based tests for good measure to fill in the gaps.
joaodlf 9y ago
In all fairness, this applies to any dynamic language - Especially scripting ones. Python, Ruby, PHP... It doesn't matter really, it's so easy for a project to grow out of control. I have growing insecurities when I program in these languages.
NumberCruncher 9y ago
>> The majority of my job consists of maintaining about a dozen legacy Rails 2 / Ruby 1.8.7 applications, written between 2008-2010, with essentially zero tests amongst them (when I started). One can write unmaintainable code in any given language/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.
bhaak 9y ago
> The majority of my job consists of maintaining about a dozen legacy Rails 2 / Ruby 1.8.7 applications, written between 2008-2010, [...] I would be sick of that, too. I'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't just lump them together. In this case, it's also not helping that they have to stay on an ancient Rails version. With Rails, it's a much smoother experience if you can follow the major releases but especially the upgrade to Rails 3 was a painful one. Edit: I don't want to imply that you shouldn't criticize Ruby but if you do, don'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't belong in there.
- mercer 9y ago
  I learned Ruby before I learned Rails, and the books/tutorials I followed were pretty heavy on the metaprogramming and OO usage (inheritance, etc.). What I find fascinating is that when I read more recent articles/books, the approach is much more functional in nature, with the OO part sometimes seeming little more than namespacing (Sandy Metz, for example). I do think Rails, for all the good stuff it did, promotes 'bad' use of Ruby. But even 'idiomatic Ruby', based on the books-you-should-read suffers from similar problems. It's all fun and exciting to write Ruby code, but if I hadn't been subjected to the 'avoid too much inheritance' and 'write your OO code in a hybrid OO-and-functional way', my output would've suffered from the same issues Rails code does. That's not to say that I dislike Ruby. I love Ruby. But it doesn't strike me as a good thing that maintainable Ruby code means avoiding a lot of the cool stuff.
  - bhaak 9y ago
    > That's not to say that I dislike Ruby. I love Ruby. But it doesn't strike me as a good thing that maintainable Ruby code means avoiding a lot of the cool stuff. Ruby is in that regard a lot like C or Perl. It gives you lots of power and options to solve a problem your way but that doesn't mean you should always do so. Rails has used those options extensively and that explains a lot of the criticism you hear about it. This also means Ruby is not for everybody but what language is? IMO you can write unmaintainable code in any language and there is none that makes that hard enough, so I'm firmly in the camp that I'd rather have the full power at my fingertips when I need it than being restricted. Although with the renaissance of functional programming, I would also love to discover a functional language that felt as fresh, powerful, and elegant as Ruby was for OO programming.
blunte 9y ago
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. 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. 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. 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've been doing are extremely expensive. That's when it stops being fun. 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's no real Rails equivalent for Clojure. (I now understand that there are great options if you're willing to cobble your own together.) Finally, you might hear of Elixir + Phoenix. Suddenly (again, if you'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. For me, it's not that Ruby is bad; it'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.
- bjz_ 9y ago
  Still no types in Elixir land, nor control over effects. Dialyzer was a real disappointment with its performance, poor error messages, lack of ecosystem support, lack of parametric polymorphism, and it not reporting obvious type errors. Really hoping for more advances in distributed type systems in the coming years, but most folks don't really need the very specialised performance envelope that the BEAM gives, and would be better off elsewhere with a type system that caught more mistakes up-front, and provided better domain modelling tools.
edu 9y ago
2014!
souenzzo 9y ago
As a clojure user, I think that testing is easy, even race condition goes trivial with clojure +datomic.
throw2016 9y ago
Most ruby apps have always been a complete pain to setup. 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. 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. 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. The same thing exists in Node and has now been adopted by the PHP ecosystem taking away the easy setup benefits of PHP.
solnic 9y ago
s/Ruby/Rails/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
blatherard 9y ago
I perused the author's blog and peeked at his LinkedIn profile. It looks like he continues to do Ruby development, and still calls himself a "Ruby on Rails Developer." I wonder what caused him to change his mind?
- jbreckmckye 9y ago
  Golden handcuffs? This is an industry that rewards specialisation. There's not many jobs for Ruby-turned-Haskell developers.
skywhopper 9y ago
(2014 btw) 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. I'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'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't save a poor design. The true test of the design is years of real use and evolution and maintenance, and so I'd love to hear from people maintaining a huge years-old Haskell codebase how it compares to other languages.
jchw 9y ago
On a sort of similar note, I'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.
AznHisoka 9y ago
Ruby is a not a great language but my main complaints are: 1. installing rvm breaks sometimes due to random code changes (i think the maintainers fix them recently) 2. they seem to think every app has just 1 database so they dont support db sharding themselves without a third party gem. 3. Net::Http is probably the most unintuitive api for crawling web pages.
oelmekki 9y ago
I've actually moved from ruby too (although, still doing some for contract work), but I wouldn't say the language is the problem, nor rails. I was more tired of the community, actually (not the opensource community, but the coworkers). Ruby and rails were awesome in the late 2000', 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. But then, soon after the start of the 2010', it started to get really ubiquitous, and there were a lot of people using it who weren't especially passionate about development. They started to make everything complicated, not bothering about trying to make things easier, and kept talking about "good practices", following them blindly without having any clue what problems they were supposed to solve. This is probably something that occurs naturally for any successful tool. I'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.
andruby 9y ago
This needs 2014 in the title. Can someone update?
emacsgifs 9y ago
2014
oliwarner 9y ago
If these programmers spent half as much time coding as they did bitching about their and others' programming environments, I think they'd get a lot more work done. Not to mention, be happier with life. Honestly, I think part of maturing into a senior software engineer (and later, a good manager) is accepting that while things aren't perfect, they're plenty good enough to solve your problems and make money. I'm not saying there aren't occasionally valid complaints, and sometimes these new tools (Docker, et al) are really good, but the sorts of developers I'm describing here always think the grass is greener when it's programmed in another language. No, of course they aren't factoring in the months it takes to convert over for a 1% productivity "boost". All this grumbling does is hasten your language and tools dropping out of fashion and never improving. If you want things to get better, contribute to your language and its tooling. If you don't, just switch out and use something else. Can we skip the swan song each time you decide something isn't good enough for you?
- lou1306 9y ago
  Fact is, they do spend a lot of time coding, but most of the code they write is either boilerplate, countermeasures to the language shortcomings, or tests to keep the language from biting you. At some point (and if the codebase is not that good to begin with) one might conclude that the language is being hostile. A bit excessive maybe, but understandable.
  - falcolas 9y ago
    This happens with every language, especially when maintaining 10 year old projects. Even a 10 year old project written by middle-of-the-bell-curve programmers in Haskell would be inducing the same amount of ire. "Who writes types this way?" "Did they even think about refactoring the existing types when bolting this other crap on?" It's the maintenance that's driving this guy nuts, not the language itself. Haskel just happens to be his side project, which will, of course, look cleaner. I felt the exact same way when moving from Perl to Python.
    - neveruseruby 9y ago
KeitIG 9y ago
"There are two kind of programming languages: the ones everybody hates and the ones nobody use."
emodendroket 9y ago
Ruby makes it really easy to write code at the cost of making it much harder to maintain.q
jrs95 9y ago
My experience with switching from static to dynamic or dynamic to static typing is that it I'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'm doing now. I probably prefer static generally, but I'm glad I'm primarily working with a dynamic language at the moment.
erik_landerholm 9y ago
If you can’t be successful writing ruby...I don’t know what to say. I’m a manager/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!
draw_down 9y ago
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.
rdsubhas 9y ago
Most problems with Rails: - Fat models (huge number of hooks, scopes, many methods stuffed inside in the name of "domain-driven design", etc) - Fat controllers (huge number of shared methods, hooks, shared variables and hooks, concerns, etc) - Fat views/helpers/templates In multiple years of working with Ruby (+/- 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, "I know what you're talking about". Models, Models, Everywhere by Chris Griego: https://speakerdeck.com/u/cgriego/p/models-models-every-where https://speakerdeck.com/u/cgriego/p/models-models-every-wher... Check out those slides, and check the codebase. This is not a Ruby problem. Splitting things mindlessly into microservices, trying to go "fully functional" (answer: nope, nothing in the world is pure or perfect), everything has trade-offs. [1] Majestic Monolith: https://m.signalvnoise.com/the-majestic-monolith-29166d022228?gi=f03ff2ca413e https://m.signalvnoise.com/the-majestic-monolith-29166d02222...
nanodano 9y ago
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.
thrownaway954 9y ago
Now that .Net is cross platform, I've been switching everything over to C#. Besides the fact that it's compiled, Visual Studio is a dream to work with.
dzink 9y ago
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's refreshing.

295 points by setra 9y ago

mattbillenstein 9y ago

... from 2014

tree_of_item 9y ago
Well, it hasn't gotten any better since then.

antirez 9y ago

I've a love/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'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's hard to use you.

pjmlp 9y ago
I think Ruby missed the opportunity to be a more general purpose language beyond Rails projects. Since its early days, I was hopping for it to gain AOT/JIT compilation support, eventually by getting some inspiration from Dylan. RubyMotion seemed to be it, but because it is commercial product, it is largely ignored by the community. The JRuby work is awesome, then again some in the Ruby community suffer from Java allergy and won't touch it. Now we have Crystal as the best way to get a bit of both worlds, AOT and Ruby like syntax, but still alpha quality.
- look_lookatme 9y ago
  I agree about Crystal, the way it dispenses with metaprogramming in favor of macros is simple and elegant and optional type restrictions gives me most of the control I want.
matthewmacleod 9y ago
Indeed, I think I really share this view. Ruby is the only programming language I've ever used where I didn't feel like I was fighting it, or struggling to express what I wanted. It was easy to express complex behaviours and data structures without reams or syntactic or structural noise. But yes – despite that, there was a lot of shoddy and poorly performing code out there. The ecosystem never saw the kind of massive investment that JS (for example) did, so performance was always lacklustre, and I'd particularly love optional typing. Still, there are other options now for specific use-cases, which is good.

Doctor_Fegg 9y ago

> 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 Because not everything I do impacts on the finances of a million people?

diminish 9y ago

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.

whostolemyhat 9y ago
What's ES6++?
- diminish 9y ago
  Javascript after ES6. I don't think we'll see ES7 etc - so I name them ES6++.

mosselman 9y ago

I don't really see how this would be much more different from language to language. The being 'sick of' 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. 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: "Writing Software by David Heinemeier Hansson" https://www.youtube.com/watch?v=9LfmrkyP81M https://www.youtube.com/watch?v=9LfmrkyP81M 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 'rules'. Like (take from the article) 'break functionality into lots of small objects'. 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/functions/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 'break things up' rule, etc. Long story short: just relax, write code (in whatever language you like, for whatever reason), go home and enjoy your family, friends and hobbies.

StreamBright 9y ago
True, however some languages have much less 'sick part' than others. It is just unfortunate that we humans tend to pick up the worse of everything. There is some hope though. In recent years there are many projects trying to provide a better programming experience and safer, faster results. Rust, ReasonML for example.
- mosselman 9y ago
  I have yet to find a better programming experience than Ruby myself, but Rust looks fine for systems programming, etc. I don't understand however why people invest so much effort in Javascript. The amount of tooling around it just baffles me, but again, to each his own.

deleted 9y ago

[deleted]

noncoml 9y ago

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

tigershark 9y ago
Basically F#
- tluyben2 9y ago
  MS still gets a lot of flack, but F# is nice imho (as is F* for the crazies like me by the way) and is getting better and better with the open source, Core etc. But for 'normal' environment, C# also just works a lot better for teams in my experience than something like Ruby. It might be just taste, but I did large projects in both and C# (also F#) make me sleep at night, while somehow the RoR stuff always needed constant attention (lot of breakage after security related gem updates etc). Nice if you have the people and need for that kind of thing, but a lot of what we do is set-and-forget (at least for a few years) which .NET allows generally. The only thing I don't like yet about the .NET dev experience is the lack of tooling, especially on Linux. But that's rapidly getting there, and is open source under a good license for the most part.
  - pjmlp 9y ago
    F# has become a second class citizen on .NET with the team catching up with what the official .NET team (C# and VB.NET) is doing across all supported platforms. Even C++ has more tooling love than what F# currently has. Anyone that wants to be sure their code will run in whatever platform Microsoft might think of supporting next, should not focus too much on it, unless the wind changes again.
  - pythonaut_16 9y ago
    The thing that frustrates me about F# is it seems to be a bit of a frontier language on .NET. Theoretically you can use it anywhere you would use C#, but there's not a ton of examples or documentation out there. Googling ".NET MVC F#" returns an article from 2010 as its top result, for example.

artellectual 9y ago

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. 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. 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. 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. 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. 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. When you find yourself blaming the tool look at yourself as an individual and look at your team.

gaius 9y ago
The same problems mentioned here plagues JavaScript yet it’s the most used language on the web. JS achieved popularity because it was the ONLY choice in its domain. That's a rarity in PLs, and can't be extrapolated to any other language that I can think of offhand.
- artellectual 9y ago
  NodeJS is a choice, not a compulsion like client side. Be sure to make that clear separation.

wiradikusuma 9y ago

I have a similar experience with Groovy, the "Ruby of Java". 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's just a prototype.

sgift 9y ago
> Yes I should have written more unit tests, but my excuse was it's just a prototype. Never understood this point "well, you don't need types, you can just write tests for it". IMO you should never have to write tests for something a type system can find for you. Why should I waste time with something which can be found by the compiler?
- zurn 9y ago
  This is the path to formal methods. You will build formally correct programs very slowly, usually too slowly for the world/app domain.
  - bjz_ 9y ago
    This need not be the case forever. It's still an open problem, but the tooling is getting better all the time! For now types+tests are a happy medium. No need to throw the baby out with the water just because 100% correctness is still unfeasible for everyday business problems.
- crdoconnor 9y ago
  I find that strict type systems are good for 'locking down' execution space and sanity checking but they're not effective at cleanly specifying higher level verification even when that's possible. I'd rather use a combination of tests and stricter type checking. There's no sense in being a fundamentalist about either approach.
  - 9y ago

raverbashing 9y ago

Ruby is "too magical" for its own sake. And then people abuse their right to use it, things like overriding class methods, etc (the syntax doesn't help in the least and it has some weird quirks when compared to python) I'd take a smoke test and some high-level functionality test before the over-testing preached by the TDD "gurus" 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'd let alone unit tested. People sell TDD like a OCD inducing religion instead of something that might be a good idea in some specific cases

crdoconnor 9y ago
>Ruby is "too magical" for its own sake Magic is extremely useful in the right place (e.g. building ORM or admin frameworks) - these can save you from writing a ridiculous amount of code. Unfortunately since it's an 'advanced' feature lots of programmers want to shove it in places where it not only isn't necessary, but is actively harmful. Python has all the same features and allows you to write code that is equally horrible (or powerful), but it benefits from a cultural bias in favor of simplicity. That said, I've still seen unnecessary magic code written by people looking to prove that they are no longer "intermediate developers". >People sell TDD like a OCD inducing religion instead of something that might be a good idea in some specific cases I think TDD with integration testing works in almost all cases, but unit tests fail or work poorly in about 85% of cases. Unfortunately, unit test driven development is what the zealots preach.
- raverbashing 9y ago
  > Magic is extremely useful in the right place (e.g. building ORM or admin frameworks) - Totally agree. Python does it in a more explicit way, so that you know "Here be Dragons" (in this object, that was defined in that specific place) It's not like a piece of casual code in any module can turn your world upside down.
- mypalmike 9y ago
  > Python has all the same features and allows you to write code that is equally horrible (or powerful), but it benefits from a cultural bias in favor of simplicity. It's not a cultural bias. It's a critical difference in the language designs. In python, monkeypatching is scoped to a module. In Ruby, monkeypatching is global to the execution environment. So in Python, you can look at the source code for a module in isolation and deterministically reason about what it does. In Ruby, you can't. Because you can't know what the execution environment will be. IMO, it's the main reason why Ruby projects become harder to manage as they grow. Somewhere, someone is monkeypatching, and reasoning about the code becomes harder and less local. I spent 2 years with Ruby and will never use it again if I can help it.

megaman22 9y ago

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.

hxegon 9y ago
It's really not as bad as people make it out to be. Really handy when you need it, and there are limiting mechanisms (refinements) for when you don't.

_Codemonkeyism 9y ago

After 10 years of the same article over and over again I'm so bored. Or sick.

cobbzilla 9y ago

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're generally safe. but there's way too much rope to hang yourself with, too much "magic", and no way to reliably refactor large codebases. As a language, it doesn't scale well into "programming in the large" unless you really know what you're doing, and most frankly don't.

lucaspiller 9y ago

I switched from Ruby (after ~8 years) to JavaScript at the beginning of this year, and Ruby is a dream in comparison: - 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. - 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. - 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. - 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'm working on has over 1000 modules in it's dependency tree.

bryanrasmussen 9y ago
I guess I have to agree with everything else, but maybe MVC isn't the best model for a JavaScript application.
dfischer 9y ago
MVC is a simple concept. You don’t need a framework to organize your modules. You can easily do MVC in Js from a vanilla setup. As another commentor suggested, maybe MVC isn’t the right abstraction for the need. That’s the balance in my experience. Sometimes it makes sense, sometimes not. In the end make the compromise that allows you to develop with high reasoning ability and iterate from there.
- meesterdude 9y ago
  > Sometimes it makes sense, sometimes not. for at least 90% of the problems out there, its the the best approach. There are a lot of design patterns out there, but you can do a lot with MVC. From what i've seen, the reason developers tend to shy away from it is because it's TOO simple. They don't feel proud of it, because its so cut and dry. They want to create something unique and interesting and challenging, even if a simple solution would do just fine. But it's not a balance, or a 50/50 sort of decision making. Really, MVC should be your first choice, and you better have a really good reason for it to not be, and a really viable alternative.

riffraff 9y ago

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

tomerbd 9y ago

You are right.

neya 9y ago

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. Having said that, now I predominantly use Phoenix/Elixir for most new projects. And the framework is moving ahead blazing fast. It has its own pros and cons, but overall, it's been a VERY positive experience and it actually saves me a LOT of time because I'm able to find code errors at compile time. It's almost the only alternative to Rails which seems like home if you'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'm amazed at the productivity I gained by using Phoenix. 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. I would never go as far as saying "I'm sick of Ruby", simply because it's still a great programming language, if you'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'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. 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's also very very chill and respectful about others' opinions. [1] Having said all this, I hope Ruby 3.0 has a strong come back which is much needed at the moment. [1] https://www.quora.com/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/answer/David-Heinemeier-Hansson https://www.quora.com/What-do-you-think-of-Elixir-and-Phoeni...

the_angry_angel 9y ago
> renamed the web folder a couple of times and so on Just to add a bit of information to this, they were all in RC or pre-releases. I was bitten by this myself, but if you choose to run RC code then you need to own that a little bit.

antod 9y ago

There's dynamic typing, but then there'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/Rails community has produced and promoted.

randomsearch 9y ago

Beware the enthusiasm of the recently converted.

iso-8859-1 9y ago
But if he had been writing Haskell for 10 years, he would become humble like most Haskellers are, and he would write no blog post at all. :P
- agumonkey 9y ago
  They're not humble or silent, they just obfuscate insult in unicode antique code points over the category of categories.
mark_l_watson 9y ago
I thought the same thing. I have written a ton of Ruby, used to be Rails, now text Processing with occasional Sinatra apps. I also write a reasonable amount of Haskell. There is no way that I am anywhere near as productive in Haskell as Ruby, but I like Haskell and for some things I very much prefer it. I would argue that it is a good thing to use two very different languages.

kristaps 9y ago

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

delta1 9y ago
I have no links to share, but it seems obvious that a dynamically typed language will need tests to ensure that a function "behaves" correctly given incorrect types, where the statically typed language will not even allow you to run that code.
bjz_ 9y ago
Testing attempts to pin down specific use cases to ensure that they meet certain requirements. Alas they only single out one case at a time - there could be a wide range of possible failure conditions you forgot to test. Types allow you to cut down the space of possibilities to a more manageable level to ensure that your testing can be more targeted. To see this pushed to the extreme, and to have a glimpse of the future, check out Edwin Brady's book "Type Driven Development with Idris": https://www.manning.com/books/type-driven-development-with-idris https://www.manning.com/books/type-driven-development-with-i... - I don't expect this style of programming to become the norm until at least another several years, but it essentially allows you to push all behavioral specifications into the types, rendering most unit testing tests obsolete. Of course I would still have smoke and integration tests to for sanity checking sake.

TimTheTinker 9y ago

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. But for core business logic? Definitely not my first choice.

meesterdude 9y ago
> But for core business logic? Definitely not my first choice. I have an alternative perspective. It's clarity, refactorability and testing ability make it a great choice for core business logic. In fact, I am yet to see a cleaner alternative. I've seen rails app's go from monolith to Go microservices, and the clarity of whats going on and agility for change is just gone. It becomes a nightmare to work with.
- TimTheTinker 9y ago
  Interesting... I personally prefer C# for core business logic. OO where you need it, great libraries & interoperability, functional programming support... good stuff. Wish I had time to look into Clojure. Excellent programming paradigm along with the interoperability, libraries, and platform support of the JVM.

sink 9y ago

This isn't really about Ruby. It'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't necessary to get the point across. The comparison could have been between Python (written in an OO fashion) and ML. You can write, 'I hate X because of dynamic typing, side effects, and object-oriented programming' 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.

lmm 9y ago
Yes and no. Ruby has a particularly dynamic, side-effecty culture, even more so than Python (where monkeypatching is less encouraged, OO is less of a focus, and, not coincidentally, unit testing is far less a source of fuss and trouble). Haskell goes in for stronger isolation of side effects than OCaml does. Any given language will be at some point on the spectrum, but Ruby and Haskell are probably the extreme ends of that spectrum as far as mainstream languages go.

keymone 9y ago

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's a perfect example of a DSL done wrong. otherwise Ruby's one of the most enjoyable language i've worked with. dynamic typing: old debate and author contributed nothing to it. side effects: with enough effort and discipline ruby can be very much functional and side effects are less of an annoyance. oop: yeah, but more specifically "what oop has become in past 30 years".

ajnin 9y ago
> side effects: with enough effort and discipline ruby can be very much functional and side effects are less of an annoyance. Not when importing a module written by someone else, as all non-trivial apps need, can impact your code.
- keymone 9y ago
  true, but over time you get better at isolating these gems (pun intended).

neilwilson 9y ago

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

lmm 9y ago
No, we really have discovered something better. We oscillate but we are converging: these days all serious statically typed languages have some level of type inference, and all serious dynamically typed languages have some level of optional type checking. We end up overcorrecting each time - Ruby was an overly dynamic, unmaintainable response to the strictness of Java, and no doubt some post-Ruby languages go too far in the straitjacket direction - but at the same time languages on both sides are better than they were previously.
- neilwilson 9y ago
  Ruby has optional type checking. What do you think the testing regime is about? It's a compiler that is built for each project with types specific to the domain problem being solved. Language type checking misses the point. The types I want to check, and the extent I want to check them, are in the spec files. Go type inference, for example, is deeply primitive and an awful lot of Go code seems to spend its time implementing duck typing via work arounds. It looks an awful lot like dependency injection for the 2010s.
  - bjz_ 9y ago
    Go is a terrible example of a statically typed language. Now that is an example of a bunch of people not learning from the past - ie. the entire lineage of ML-based languages! A rich type system lets you mold and shape the types to fit nicely over your domain, effectively becoming a machine-verified DSL for your business problem. It will catch flaws in your mental model before you even begin to write tests or an implementation, and is a cheap way of sketching out your ideas and great documentation to have over the lifetime of your project. Of course you can't fit it exactly, so you need a smattering of spec tests, and probably some property-based tests for good measure to fill in the gaps.

joaodlf 9y ago

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

NumberCruncher 9y ago

>> The majority of my job consists of maintaining about a dozen legacy Rails 2 / Ruby 1.8.7 applications, written between 2008-2010, with essentially zero tests amongst them (when I started). One can write unmaintainable code in any given language/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.

bhaak 9y ago

> The majority of my job consists of maintaining about a dozen legacy Rails 2 / Ruby 1.8.7 applications, written between 2008-2010, [...] I would be sick of that, too. I'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't just lump them together. In this case, it's also not helping that they have to stay on an ancient Rails version. With Rails, it's a much smoother experience if you can follow the major releases but especially the upgrade to Rails 3 was a painful one. Edit: I don't want to imply that you shouldn't criticize Ruby but if you do, don'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't belong in there.

mercer 9y ago
I learned Ruby before I learned Rails, and the books/tutorials I followed were pretty heavy on the metaprogramming and OO usage (inheritance, etc.). What I find fascinating is that when I read more recent articles/books, the approach is much more functional in nature, with the OO part sometimes seeming little more than namespacing (Sandy Metz, for example). I do think Rails, for all the good stuff it did, promotes 'bad' use of Ruby. But even 'idiomatic Ruby', based on the books-you-should-read suffers from similar problems. It's all fun and exciting to write Ruby code, but if I hadn't been subjected to the 'avoid too much inheritance' and 'write your OO code in a hybrid OO-and-functional way', my output would've suffered from the same issues Rails code does. That's not to say that I dislike Ruby. I love Ruby. But it doesn't strike me as a good thing that maintainable Ruby code means avoiding a lot of the cool stuff.
- bhaak 9y ago
  > That's not to say that I dislike Ruby. I love Ruby. But it doesn't strike me as a good thing that maintainable Ruby code means avoiding a lot of the cool stuff. Ruby is in that regard a lot like C or Perl. It gives you lots of power and options to solve a problem your way but that doesn't mean you should always do so. Rails has used those options extensively and that explains a lot of the criticism you hear about it. This also means Ruby is not for everybody but what language is? IMO you can write unmaintainable code in any language and there is none that makes that hard enough, so I'm firmly in the camp that I'd rather have the full power at my fingertips when I need it than being restricted. Although with the renaissance of functional programming, I would also love to discover a functional language that felt as fresh, powerful, and elegant as Ruby was for OO programming.

blunte 9y ago

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. 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. 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. 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've been doing are extremely expensive. That's when it stops being fun. 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's no real Rails equivalent for Clojure. (I now understand that there are great options if you're willing to cobble your own together.) Finally, you might hear of Elixir + Phoenix. Suddenly (again, if you'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. For me, it's not that Ruby is bad; it'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.

bjz_ 9y ago
Still no types in Elixir land, nor control over effects. Dialyzer was a real disappointment with its performance, poor error messages, lack of ecosystem support, lack of parametric polymorphism, and it not reporting obvious type errors. Really hoping for more advances in distributed type systems in the coming years, but most folks don't really need the very specialised performance envelope that the BEAM gives, and would be better off elsewhere with a type system that caught more mistakes up-front, and provided better domain modelling tools.

edu 9y ago

2014!

souenzzo 9y ago

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

throw2016 9y ago

Most ruby apps have always been a complete pain to setup. 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. 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. 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. The same thing exists in Node and has now been adopted by the PHP ecosystem taking away the easy setup benefits of PHP.

solnic 9y ago

s/Ruby/Rails/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

blatherard 9y ago

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

jbreckmckye 9y ago
Golden handcuffs? This is an industry that rewards specialisation. There's not many jobs for Ruby-turned-Haskell developers.

skywhopper 9y ago

(2014 btw) 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. I'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'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't save a poor design. The true test of the design is years of real use and evolution and maintenance, and so I'd love to hear from people maintaining a huge years-old Haskell codebase how it compares to other languages.

jchw 9y ago

On a sort of similar note, I'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.

AznHisoka 9y ago

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

oelmekki 9y ago

I've actually moved from ruby too (although, still doing some for contract work), but I wouldn't say the language is the problem, nor rails. I was more tired of the community, actually (not the opensource community, but the coworkers). Ruby and rails were awesome in the late 2000', 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. But then, soon after the start of the 2010', it started to get really ubiquitous, and there were a lot of people using it who weren't especially passionate about development. They started to make everything complicated, not bothering about trying to make things easier, and kept talking about "good practices", following them blindly without having any clue what problems they were supposed to solve. This is probably something that occurs naturally for any successful tool. I'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.

andruby 9y ago

This needs 2014 in the title. Can someone update?

emacsgifs 9y ago

2014

oliwarner 9y ago

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

lou1306 9y ago
Fact is, they do spend a lot of time coding, but most of the code they write is either boilerplate, countermeasures to the language shortcomings, or tests to keep the language from biting you. At some point (and if the codebase is not that good to begin with) one might conclude that the language is being hostile. A bit excessive maybe, but understandable.
- falcolas 9y ago
  This happens with every language, especially when maintaining 10 year old projects. Even a 10 year old project written by middle-of-the-bell-curve programmers in Haskell would be inducing the same amount of ire. "Who writes types this way?" "Did they even think about refactoring the existing types when bolting this other crap on?" It's the maintenance that's driving this guy nuts, not the language itself. Haskel just happens to be his side project, which will, of course, look cleaner. I felt the exact same way when moving from Perl to Python.
  - neveruseruby 9y ago

KeitIG 9y ago

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

emodendroket 9y ago

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

jrs95 9y ago

My experience with switching from static to dynamic or dynamic to static typing is that it I'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'm doing now. I probably prefer static generally, but I'm glad I'm primarily working with a dynamic language at the moment.

erik_landerholm 9y ago

If you can’t be successful writing ruby...I don’t know what to say. I’m a manager/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!

draw_down 9y ago

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.

rdsubhas 9y ago

Most problems with Rails: - Fat models (huge number of hooks, scopes, many methods stuffed inside in the name of "domain-driven design", etc) - Fat controllers (huge number of shared methods, hooks, shared variables and hooks, concerns, etc) - Fat views/helpers/templates In multiple years of working with Ruby (+/- 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, "I know what you're talking about". Models, Models, Everywhere by Chris Griego: https://speakerdeck.com/u/cgriego/p/models-models-every-where https://speakerdeck.com/u/cgriego/p/models-models-every-wher... Check out those slides, and check the codebase. This is not a Ruby problem. Splitting things mindlessly into microservices, trying to go "fully functional" (answer: nope, nothing in the world is pure or perfect), everything has trade-offs. [1] Majestic Monolith: https://m.signalvnoise.com/the-majestic-monolith-29166d022228?gi=f03ff2ca413e https://m.signalvnoise.com/the-majestic-monolith-29166d02222...

nanodano 9y ago

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.

thrownaway954 9y ago

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

dzink 9y ago

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's refreshing.